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

Chris Lattner clattner at apple.com
Fri Mar 2 18:38:45 PST 2012


On Mar 2, 2012, at 3:00 PM, Duncan Sands wrote:
>>> 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.
> 
> I was just trying to say that I'm not sure that this is a big deal, since passes
> already have to handle implicit funky dominance relations.  In the case of my
> example: definitions are supposed to dominate uses, which in the case of
> A = bitcast ty B, B = bitcast ty' A means that A has to dominate B and B has
> to dominate A, i.e. exactly the kind of funky dom relation you mentioned (an
> implicit one).

Ok, I can buy that.

>>>> 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.
> 
> It would be nice if dominates(definition,use_of_definition) were always true.
> Since unreachable instructions can clearly use reachable instructions, that
> gives
>  dominates(reachable, unreachable) -> true
> On the other hand, reachable instructions shouldn't be using unreachable
> instructions:
>  dominates(unreachable, reachable) -> false
> Since unreachable instructions can be using other unreachable instructions,
> I think you're obliged to have
>  dominates(unreachable, unreachable) -> true

The most important thing for me is that dominance of blocks and dominance of instructions follow the same rules.  Beyond that, I'm pretty ok with anything.  If you think that returning true makes sense, feel free to make it so (just don't break anything ;-)

-Chris




More information about the llvm-commits mailing list