[llvm-commits] [llvm] r144267 - in /llvm/trunk: lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp test/CodeGen/X86/2006-05-11-InstrSched.ll test/CodeGen/X86/2009-04-21-NoReloadImpDef.ll test/CodeGen/X86/change-compare-stride-1.ll test/CodeGen/X86/fold-pcmpeqd-0.ll test/CodeGen/X86/iv-users-in-other-loops.ll test/CodeGen/X86/lsr-loop-exit-cond.ll test/CodeGen/X86/lsr-reuse-trunc.ll test/CodeGen/X86/masked-iv-safe.ll test/CodeGen/X86/multiple-loop-post-inc.ll test/CodeGen/X86/sse2.ll test/CodeGen/X86/sse3.ll

Duncan Sands baldrick at free.fr
Tue Nov 15 12:46:18 PST 2011


Hi Rafael,

>>> That's really bizarre. It's obviously exposing a unrelated bug. Thanks for looking into this.
>>
>> I think this is a case of PR11200: the code generators make decisions based on
>> floating point computations.  On i386, GCC uses the floating point stack, while
>> LLVM uses xmm registers, when building LLVM.  This results in codegen sometimes
>> making different decisions due to different rounding.
>
> Can't we just use -msse when building stage1 or do a bootstrap4?

alternatively, maybe all floating point computations should be removed from the
code generator.

Ciao, Duncan.

>
>> I've disabled the part of the dragonegg bootstrap that compares object files
>> produced by GCC compiled LLVM with those produced by LLVM compiled LLVM as a
>> workaround.
>>
>> Ciao, Duncan.
>
> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list