[llvm-commits] [llvm] r151466 - in /llvm/trunk: include/llvm/Analysis/Dominators.h lib/Analysis/InstructionSimplify.cpp

[Chris Lattner]

On Mar 2, 2012, at 1:28 PM, Duncan Sands wrote:
>>> why not?  Is there really no sensible definition of domination in this case?
>> 
>> There is no good answer.  The definition of dom(A,B) is "all paths from the entry block to B go through A".  This is vacuously true for unreachable blocks, but it is unlikely that any transformation would be prepared to handle this (because now you can have dom(a,b) = true and dom(b,a) = true and a != b).
> 
> all kinds of transformations already have to handle this, in fact you hit an
> example yourself not long ago: when removing bitcasts from an instruction in
> an unreachable block, it is possible that after peeling of a number of bitcasts
> you get back to the original instruction!

I'm not sure what you mean, of course code has to handle unreachable blocks.  That doesn't mean anything specific for the dominators API though.

>> 
>> Yes, I think it is worth being consistent here.  For blocks, we return false in this case iirc, which would be better than returning true.
> 
> See for example the implementation of isReachableFromEntry.  If some value for
> "dominates" with unreachable basic blocks falls naturally out of the dominators
> computation, maybe whatever that is (is it really just "false" always?) can be
> extended to dominates(instr,instr).

Returning false all the time would work for me.

-Chris