Florian Hahn via llvm-dev
2021-Mar-15 10:32 UTC
[llvm-dev] Invalid llvm-ir and unreachable code
> On Mar 15, 2021, at 09:53, Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Roman, > > [..] >>> >>> - 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' ? >> I've just adjusted that function in 36f1c3db66f7268ea3183bcf0bbf05b3e1c570b4 >> to assert that no cycles are encountered instead of endlessly looping. >> >> But i *think* the problem is in your SROA changes. >> Can you link me to the particular patch in question? > > This is the patch that triggers the unbounded lookup: https://reviews.llvm.org/D68507 > (llvm/lib/Analysis/ScopedNoAliasAA.cpp, line 269) > > I checked again the endless loop: It happens _right after SROA_, in the MemorySSA pass. >Can you isolate the failure to just a run of MemorySSA? If so, it sounds like it would be a problem in your linked patch. I guess it would be good to know exactly where an infinite loop is triggered (and why).
Nikita Popov via llvm-dev
2021-Mar-15 10:37 UTC
[llvm-dev] Invalid llvm-ir and unreachable code
On Mon, Mar 15, 2021 at 11:32 AM Florian Hahn via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > > On Mar 15, 2021, at 09:53, Jeroen Dobbelaere via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi Roman, > > > > [..] > >>> > >>> - 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' ? > >> I've just adjusted that function in > 36f1c3db66f7268ea3183bcf0bbf05b3e1c570b4 > >> to assert that no cycles are encountered instead of endlessly looping. > >> > >> But i *think* the problem is in your SROA changes. > >> Can you link me to the particular patch in question? > > > > This is the patch that triggers the unbounded lookup: > https://reviews.llvm.org/D68507 > > (llvm/lib/Analysis/ScopedNoAliasAA.cpp, line 269) > > > > I checked again the endless loop: It happens _right after SROA_, in the > MemorySSA pass. > > > Can you isolate the failure to just a run of MemorySSA? If so, it sounds > like it would be a problem in your linked patch. I guess it would be good > to know exactly where an infinite loop is triggered (and why). >The infinite loop happens because getUnderlyingObject() is called with MaxLookup=0. getUnderlyingObject() relies on a finite depth limit to prevent infinite loops. The problem is specific to the full restrict patch for this reason -- normally we don't perform unlimited getUnderlyingObject() calls. The correct fix here is imho to remove the ability to call getUnderlyingObject() with MaxLookup=0, which sounds like a bad idea for pathological cases anyway. Nikita -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210315/d814cecf/attachment.html>