[LLVMdev] Jump Theading/GVN bug - moving discussion to llvm-dev

[Philip Reames]

On 02/24/2015 10:52 AM, Philip Reames wrote:
>
> On 02/23/2015 08:45 PM, Hal Finkel wrote:
>> I don't disagree with this, but I think there are two (separable) 
>> issues here:
>>
>>   1. Should transformations produce unreachable code? On the face of 
>> it, they must be able to, because the problem of determining dynamic 
>> reachability is generally undecidable. Should passes produce 
>> trivially dead code? Well, probably not if they avoid it. Even this 
>> is not locally decidable, and so you're right, removing it will add 
>> extra expense (but also provide savings, so we'd need to experiment).
>>
>>   2. Should unreachable code be allowed to contain nonsense (like 
>> instructions that depend on themselves)? To this, I believe the 
>> answer is no. We currently permit this, and I think that a lot of the 
>> bugs regarding unreachable code some from this. I've yet to hear a 
>> good argument why, for example, JumpThreading must produce 
>> self-referential instructions in trivially-dead regions.
>>
>>   -Hal
> I agree with Hal here.  Fixing (2) does not necessarily involve 
> changing (1).  Can someone sketch out how we'd ever get an instance of 
> (2)?  I'd naively expect to at least see a PHI in the cycle.
The only use of dominance information I can find in JT/LVI is for the 
handling for @llvm.assume in ValueTracking.  Adding a 
DT->isReachableFromEntry check to this path seems downright simple.

On the surface, I don't see why the LVI analysis would care about 
unreachable blocks.  It's only looking at the edges in the CFG and would 
treat an unreachable region the same as a reachable one.

Philip