[llvm-dev] Invalid llvm-ir and unreachable code

Jeroen Dobbelaere via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 12 00:59:24 PST 2021


> > Hi all,
> >
> > I have found a case where an optimization pass is barfing on invalid code in
> an unreachable
> > basic block. A self referencing GEP '%x = getelementptr %x, 0, 1' is found
> inside a cycle of
> > two unreachable basic blocks)
> >
> > The invalid code and the unreachable basic blocks were introduced by the
> function inliner.
> >
> > I am wondering what is valid for these cases ?
> > (I did not find anything in LangRef, but I might as well have missed it)
> >
> > - clearly 'dead code' (aka unreachable basic blocks) is valid in an IR ?
> Yep.
> 
> > - I assume that the self reference in dead code is not valid ?
> Unreachable code is permitted to take various weird shapes and forms.
> So no, that is valid.
> 
> > - should inlining do an extra effort of cleaning up such dead code blocks ?
> >
> 
> Which pass?

As far as I see, it is in SROA (and a combination of our custom changes, including the full restrict changes).
I am not sure yet if it is a generic SROA problem or not, but if it is, I should be able
to create a bugreport.

> Generally, it (or the users of that code) should either use DominatoTree
> to avoid handling unreachable blocks, or it should be hardened to deal
> with such situations gracefully.

Thanks,

Jeroen Dobbelaere






More information about the llvm-dev mailing list