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

[Jeroen Dobbelaere via llvm-dev]

>> [..]
>>>> 
>>>> - 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.

I agree. IIRC this lookup originates from the original 'local restrict support'. I think we should be able to cope with a limited depth lookup.
At worst case, it should modify the result of a scoped noalias query to return 'MayAlias' over 'NoAlias'.

Greetings,

Jeroen