<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 15, 2021 at 11:32 AM Florian Hahn via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 15, 2021, at 09:53, Jeroen Dobbelaere via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hi Roman,<br>
> <br>
> [..]<br>
>>> <br>
>>> - the problematic code construct consists of a cycle of 'dead' basic blocks<br>
>> that conditionally jumps into live blocks.<br>
>>> <br>
>>>  That jump introduce a connection of a dead self-referring 'getelementptr'<br>
>> to live code through a PHI node.<br>
>>> <br>
>>> - during SROA, the scoped noalias analysis (full restrict version) does an<br>
>> unbounded (MaxLookup == 0) 'getUnderlyingObject' call on a pointer.<br>
>>> <br>
>>> - 'getUnderlyingObject' also follows the path to the dead blocks and ends up<br>
>> in the self-referring  'getelementpr'.<br>
>>> <br>
>>> <br>
>>> <br>
>>> Does this mean that 'getUnderlyingObject' should also be prepared to be<br>
>> handling 'invalid instructions' in 'dead code' ?<br>
>> I've just adjusted that function in 36f1c3db66f7268ea3183bcf0bbf05b3e1c570b4<br>
>> to assert that no cycles are encountered instead of endlessly looping.<br>
>> <br>
>> But i *think* the problem is in your SROA changes.<br>
>> Can you link me to the particular patch in question?<br>
> <br>
> This is the patch that triggers the unbounded lookup:  <a href="https://reviews.llvm.org/D68507" rel="noreferrer" target="_blank">https://reviews.llvm.org/D68507</a><br>
> (llvm/lib/Analysis/ScopedNoAliasAA.cpp, line 269)<br>
> <br>
> I checked again the endless loop: It happens _right after SROA_, in the MemorySSA pass.<br>
> <br>
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).<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Nikita<br></div></div></div>