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

[Jeroen Dobbelaere via llvm-dev]

Thanks for all the feedback !

The issue I encountered is likely not happening on the main llvm, but I believe the issue is interesting enough to
document:

- the problematic code construct consists of a cycle of 'dead' basic blocks that conditionally jumps into live blocks.
  That jump introduce a connection of a dead self-referring 'getelementptr' to live code through a PHI node.
- during SROA, the scoped noalias analysis (full restrict version) does an unbounded (MaxLookup == 0) 'getUnderlyingObject' call on a pointer.
- 'getUnderlyingObject' also follows the path to the dead blocks and ends up in the self-referring  'getelementpr'.

Does this mean that 'getUnderlyingObject' should also be prepared to be handling 'invalid instructions' in 'dead code' ?

Greetings,

Jeroen Dobbelaere


From: Mehdi AMINI <joker.eph at gmail.com>
Sent: Sunday, March 14, 2021 05:05
To: Jeroen Dobbelaere <dobbel at synopsys.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Invalid llvm-ir and unreachable code



On Fri, Mar 12, 2021 at 12:47 AM Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org<mailto: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<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!PhY5mSTbBqeon1sexwPIOPVE-FV5TSJEF8q7Z7rlgk7EkgrRtxHjDS1zmWcoAX1gOmpBR9Z4$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210315/e8f48fea/attachment.html>