[x86] Avoid memory form of PUSH/CALL for ATOM.

src/x64/assembler-x64.cc

 // Copyright 2012 the V8 project authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "src/x64/assembler-x64.h"
 
 #if V8_OS_MACOSX
 #include <sys/sysctl.h>
 #endif
 
@@ skipping 42 matching lines @@
 
   // Only use statically determined features for cross compile (snapshot).
   if (cross_compile) return;
 
   if (cpu.has_sse41() && FLAG_enable_sse4_1) supported_ |= 1u << SSE4_1;
   if (cpu.has_sse3() && FLAG_enable_sse3) supported_ |= 1u << SSE3;
   // SAHF is not generally available in long mode.
   if (cpu.has_sahf() && FLAG_enable_sahf) supported_ |= 1u << SAHF;
   if (cpu.has_avx() && EnableAVX()) supported_ |= 1u << AVX;
   if (cpu.has_fma3() && FLAG_enable_fma3) supported_ |= 1u << FMA3;
+  if (cpu.is_atom()) FLAG_intel_atom = true;

[Benedikt Meurer, 2015/01/19 05:39:25]

Modifying flags this way is a bad idea, and it also defeats the purpose of the
flag completely, because now whenever the CPU class detects an ATOM, the
intel-atom flag will be forcibly true.

[Weiliang, 2015/01/19 05:51:01]

Maybe I miss something?
The logic here: the intel_atom flag is FALSE by default. It is only true if CPU
detects an ATOM or you require it by using "--intel_atom" flag. The latter eases
the test of ATOM specific code path on non-ATOM devices. 

[Benedikt Meurer, 2015/01/19 05:57:22]

Yes, but you cannot generally test the backend code independent of the CPU that
you are running on. If you happen to run on something that claims to be an ATOM,
you'll always be forced into the ATOM code path. A similar problem exists for
the ATOM CpuFeatures flag, however. Ideally the --intel-atom flag would forcibly
enable the ATOM code path, while --nointel-atom forcibly disables it, and
autodetection  is only used if neither flag is given. However that's not how our
flags work.

So how about this solution: Add a string flag --mcpu=<cpu> with <cpu> default to
"auto". This can be used in general and is not limited to this ATOM thing.

Sven, danno: WDYT?

[Sven Panne, 2015/01/19 07:42:14]

I agree with Benedikt: Modifying flags is a no-go for several reasons, adding a
new flag seems to be the way to go. Tiny bikeshedding: I would prefer
--march=<arch> because we talk about architectures, not CPUs, and this is more
in line with the GCC/clang flag names.

 }
 
 
 void CpuFeatures::PrintTarget() { }
 void CpuFeatures::PrintFeatures() {
   printf("SSE3=%d SSE4_1=%d SAHF=%d AVX=%d FMA3=%d\n",
          CpuFeatures::IsSupported(SSE3), CpuFeatures::IsSupported(SSE4_1),
          CpuFeatures::IsSupported(SAHF), CpuFeatures::IsSupported(AVX),
          CpuFeatures::IsSupported(FMA3));
 }
@@ skipping 3307 matching lines @@
 
 
 bool RelocInfo::IsInConstantPool() {
   return false;
 }
 
 
 } }  // namespace v8::internal
 
 #endif  // V8_TARGET_ARCH_X64