[v8-dev] ARM: Improve Lithium register constraints.

src/globals.h

 // Copyright 2012 the V8 project authors. All rights reserved.
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 //
 //     * Redistributions of source code must retain the above copyright
 //       notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
 //       copyright notice, this list of conditions and the following
 //       disclaimer in the documentation and/or other materials provided
@@ skipping 145 matching lines @@
 #elif V8_TARGET_ARCH_X64
 #define V8_TARGET_LITTLE_ENDIAN 1
 #elif V8_TARGET_ARCH_ARM
 #define V8_TARGET_LITTLE_ENDIAN 1
 #elif V8_TARGET_ARCH_MIPS
 #define V8_TARGET_LITTLE_ENDIAN 1
 #else
 #error Unknown target architecture endiannes
 #endif
 
+#if V8_TARGET_ARCH_ARM
+// On ARM, for some arithmetic instructions, the macro assembler defines
+// XXXMemOperand macro instructions which are able to load the right operand
+// from memory.
+#define V8_BETTER_OPERAND_ON_RIGHT

[Benedikt Meurer, 2013/08/20 11:55:34]

I don't like this #define. Why not switch the order for the XXXMemOperand macro
instructions and use the existing logic?

[vincent.belliard.fr, 2013/08/22 12:35:48]

Once again, the code has been made for IA32 where operands only used once are
better at left because operations clobber the left value.
With ARM, we have 3 operands operations so there is no advantage to put used
once operands on the left.

The XXXMemOperand functions could have been defined with the MemOperand on the
left instead of on the right. However, it would have been not consistent with
other macro assembler functions.

The choice of left operand is arbitrary (but this is good for IA32). We only put
this define to be able to make the better choice for a CPU.

It was difficult to find a good name for the define (and we can't use the
ARCH_ARM define directly in hydrogen-instructions.h). If you have some
suggestions we can change the name.

[Benedikt Meurer, 2013/08/23 07:41:02]

I still don't see why this macro is needed at all. As you say, ARM has 3 operand
instructions, so it doesn't matter and we could as well have the better operand
on the left there as well. What am I missing? 

+#endif
+
 // Support for alternative bool type. This is only enabled if the code is
 // compiled with USE_MYBOOL defined. This catches some nasty type bugs.
 // For instance, 'bool b = "false";' results in b == true! This is a hidden
 // source of bugs.
 // However, redefining the bool type does have some negative impact on some
 // platforms. It gives rise to compiler warnings (i.e. with
 // MSVC) in the API header files when mixing code that uses the standard
 // bool with code that uses the redefined version.
 // This does not actually belong in the platform code, but needs to be
 // defined here because the platform code uses bool, and platform.h is
@@ skipping 338 matching lines @@
 // the backend, so both modes are represented by the kStrictMode value.
 enum StrictModeFlag {
   kNonStrictMode,
   kStrictMode
 };
 
 
 } }  // namespace v8::internal
 
 #endif  // V8_GLOBALS_H_