How to track down a bad llvm optimization pass

[Johan Engelen via digitalmars-d-ldc]

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!