llvm dev - Mar 2021 - Invalid llvm-ir and unreachable code

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 ?
- I assume that the self reference in dead code is not valid ?
- should inlining do an extra effort of cleaning up such dead code blocks ?

Thanks,

Jeroen Dobbelaere

On Fri, Mar 12, 2021 at 11:47 AM Jeroen Dobbelaere via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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?
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
Roman
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Fri, Mar 12, 2021 at 12:47 AM Jeroen Dobbelaere via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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 ?
> - I assume that the self reference in dead code is not valid ?
>
Yes, self-references are valid in unreachable code, we have test cases for
this, it'll pass the verifier. Passes should be resilient against this
(even though a pass could always do a quick reachability check and delete
all dead blocks as a pre-step).

-- 
Mehdi


> - should inlining do an extra effort of cleaning up such dead code blocks ?
>
> Thanks,
>
> Jeroen Dobbelaere
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210313/a217ae70/attachment.html>