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

Duncan Sands baldrick at free.fr
Fri Mar 2 15:00:43 PST 2012


Hi Chris,

On 02/03/12 22:40, Chris Lattner wrote:
> 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.

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

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

Ciao, Duncan.



More information about the llvm-commits mailing list