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

Florian Hahn via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 15 03:32:17 PDT 2021



> 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).


More information about the llvm-dev mailing list