Optimization bug on atom processors and/or subtarget for atom

[graydon]

@rillian and @evanmcc have both encountered a build failure -- same place -- stage1 segfaults when building optimized on atom. Seems independent of distribution, (happens on FC17 and Ubuntu oneiric). Both machines were atoms. Tried builds on emulated non-atoms, same distros, no fault. Think it's atom-specific. Might be a duplicate of #1879 (requirement for subtargets).

[rillian]

Confirmed. If I configure with --disable-optimized, it completes 'make check':

result: ok. 142 passed; 0 failed; 0 ignored

followed by the known valgrind complaint.

My machine is an Intel Atom N475.

[evanmcc]

Mine is an Atom D525.

[j3parker]

Confirmed: One Atom 330 running Ubuntu Natty, one running Ubuntu Maverick.
The end of the build looks like:

cp: x86_64-unknown-linux-gnu/stage1/lib/librustc.so
cp: x86_64-unknown-linux-gnu/stage1/bin/rustc
compile_and_link: x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libcore.so
Segmentation fault
make: *** [x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libcore.so] Error 139

[evanmcc]

I have managed to get this working with optimization on by doing horrible, horrible things.

1. hacked configure to have an option to use local rust
2. build a local, non-optimized rust with the cpustring in RustWrapper.cpp set statically to x86-64
3. reconfigure to being optimizing and using the local rust.

so it does look like something about the atom code is messing rust up.

next step is to make it so I can pass in feature strings, to see in which atom feature this problem occurs (assuming a non-blank feature string overrides the standard featureset the cpu comes with).

[graydon]

Oh weird. So it works on atom when you force it to pretend it's not on an atom?

[evanmcc]

So part of the problem is that the current code sniffs the host cpu in all cases. It might be that the right thing to do here is to just assume the most generic cpu we can (i686, x86-64) in cases where --opt-level is < 2, instead of having a special wide-distribution option or having to differentiate the targets in these simple cases.

I am digging around in LLVM to see how this stuff is used and set.

A couple of things would be useful here:

• could you post or message me the output of cat /proc/cpuinfo on the 64-bit linux build machine?
• does rust do any inline asm? There are two code paths that use the feature string and cpu type and being able to ignore one of them would be nice.

[evanmcc]

A few more words about my strategy here:

At this point I am removing features from the LLVM impl of atom to see which of them is causing the segfault. There is likely a cleaner way to do this, but this was the simplest and most likely to work cleanly (if most time-consuming). I need to understand better what LLVM is doing internally with the feature string.

I figure that if we can figure out which optimization is causing the failure, we should be able to figure out why it's failing and perhaps fix it.

[evanmcc]

The feature that's causing the issue is "ProcIntelAtom". Going to try to figure out what it actually does.

[evanmcc]

Even more specifically, the line:
PostRAScheduler = true;
in src/llvm/lib/Target/X86/X86Subtarget.cpp is causing the issue.

generating some binaries with hopefully the smallest possible code change so someone can look at them side by side.

[flo-dhalluin]

Just to confirm I have also have the segfault : debian squeeze with a N270 (non x64 )

[donpdonp]

I too have the segfault, Atom D510, Gentoo GCC 4.4.5. As requested, /proc/cpuinfo reads

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz
stepping : 10
cpu MHz : 1666.729
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dts
bogomips : 3333.45
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

[donpdonp]

It appears the LLVM project has a patch for this now.

http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/112078