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

[Nikita Popov via llvm-dev]

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>