How to track down a bad llvm optimization pass

Joakim via digitalmars-d-ldc digitalmars-d-ldc at
Thu Jun 30 08:40:53 PDT 2016

On Thursday, 30 June 2016 at 12:33:21 UTC, Johan Engelen wrote:
> On Thursday, 30 June 2016 at 11:50:15 UTC, Joakim wrote:
>> Speaking of shift errors, I took a look at why even ldc 1.0.0 
>> fails for that undefined shift optimization bug I just 
>> reported for dmd and it does the same thing, simply removes 
>> the test block after inlining and optimization.
>> Here's the relevant IR before and after inlining with -O1 
>> -enable-inlining on linux/x64:
>> *** IR Dump Before Function Integration/Inlining ***
>> ; Function Attrs: uwtable
>> define void @_D5shift14__unittestL2_1FZv() #1 comdat {
>>   %1 = call i32 @_D5shift11check_shiftFiZi(i32 3) #1
>>   %2 = icmp eq i32 %1, 16
>>   br i1 %2, label %assertPassed, label %assertFailed
>> *** IR Dump After Function Integration/Inlining ***
>> ; Function Attrs: uwtable
>> define void @_D5shift14__unittestL2_1FZv() #1 comdat {
>> %1 = icmp eq i32 undef, 16
>> br i1 %1, label %assertPassed, label %assertFailed
>> Eventually that gets optimized away to nothing, just like with 
>> dmd.
>> Would this be considered an llvm bug or the expected result 
>> from passing an undefined right shift to llvm?  It should at 
>> least warn about that undef after inlining, shouldn't it?
> I am not a big LLVM expert, but I would not expect a warning at 
> all. I think "undef" is used e.g. by frontends (e.g. LDC) to 
> allow LLVM to optimize certain constructs. I'm guessing LLVM is 
> thinking: "undef", great!, let's optimize the hell out of it!

I assumed that undef was some kind of poison value, but it looks 
like it's normally used:

I guess the issue then is whether the inlining pass should just 
be returning undef from evaluating check_shift(3), and moving on 
happily from there.  Since this is at compile-time, I don't think 
it should.

Does anyone know what llvm's stance is on this?  Are we supposed 
to be running sanitizers or something else to avoid these bugs?

More information about the digitalmars-d-ldc mailing list