[llvm-commits] [llvm] r146604 - in /llvm/trunk: lib/CodeGen/MachineSink.cpp test/CodeGen/ARM/2011-12-14-machine-sink.ll

[Akira Hatanaka]

It turns out that the failure was caused by a bug in
MipsInstrInfo::storeRegToStackSlot and loadRegFromStackSlot. A
MachineMemOperand was not being added to the generated instruction,
which was causing MachineLICM to incorrectly determine it is safe to
move a load out of a loop. So this wasn't a mis-compilation caused by
a bug in Machine Sink or the register allocator.

Sorry for the false alarm and thank you for your help.

2011/12/21 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>:
> On 21/12/11 02:57 AM, Anton Korobeynikov wrote:
>>> One alternative for you is to reproduce segfault in debugger and investigate what is being compiled.
>>>
>>> Other alternative is to narrow down the particular MI sink that is difference maker. You can do this by disabling this patch and adding a artificial threshold in Machine Sink pass to control how many instructions are sinked. One you know the critical MI sink, you can investigate how it impacts other passes, including register allocator, down the road.
>>>
>>> I am afraid, there is not any easy answer.
>> Previously one could use bugpoint to reduce such problems
>> automatically via splitting the code into two parts, compiling one
>> part with gcc and another - via llvm.
>> Though, I doubt this will work right now since cbe is broken now. That
>> said, you do not have any automatic reduction in such cases and should
>> do everything by hands.
>>
>
> Bugpoint can use a "safe llc", so it might be possible to use "llc
> -regalloc=basic" as the safe compiler, but I haven't used that recently.
>
> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits