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

src/x64/assembler-x64.cc

Index: src/x64/assembler-x64.cc
diff --git a/src/x64/assembler-x64.cc b/src/x64/assembler-x64.cc
index 96422f6863fa86b90b655f3568680a48e61f6731..9a09880fae69acec79acd98ee8370610d968899a 100644
--- a/src/x64/assembler-x64.cc
+++ b/src/x64/assembler-x64.cc
@@ -60,6 +60,7 @@ void CpuFeatures::ProbeImpl(bool cross_compile) {
   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.

 }