[PATCH] D11861: [IR] Add token types

[John McCall via llvm-commits]

rjmccall added a comment.

In http://reviews.llvm.org/D11861#224049, @majnemer wrote:

> The following has `Value *` which cannot be demoted, it passes the verifier:


I assume it crashes all the backends, though.  Still, interesting; do you know if that's intentional?

> > > > Anyway, I am not deeply objecting to the feature; I would just like to understand why you need it for EH.

> 

> > 

> 

> > > 

> 

> > 

> 

> > > 

> 

> > 

> 

> > > My cleanup is materialized as a funclet which, by definition, has a single entry point.  My personality routine has a restriction which requires that a cleanup transfer control to a single, specific, successor.  This restriction comes about by the format of the unwind information that my personality routine uses to control its behavior, the cleanup has no mechanism to communicate where it would like to go next.  I am in trouble if I have a `cleanuppad` which can reach two `cleanupret`s with different successors.  By having my `cleanuppad` produce a value which may not be obscured and consume it in my `cleanupret`, I know that I can disregard other `cleanupret` instructions which appear reachable in the CFG but are dynamically unreachable.

> 

> > 

> 

> > 

> 

> > What happens if the cleanupret becomes unreachable?

> 

> 

> Then we are left with a `cleanuppad` whose `Value *` is unused and the `cleanupret` would be deleted.  This should be fine.

> 

> >   Also, it doesn't sound like you really need a restriction that the token can't be used in multiple places: if someone cloned the cleanupret, you could make that work pretty easily by just creating multiple returns from your funclet.

> 

> 

> I can have multiple returns from my funclet, they just all have to go to the same place.

> 

> A token value can be used in multiple places, the users can be cloned just fine.  What cannot be cloned is the instruction which produces the value as any `phi` nodes would be problematic.


Okay.  But cloning the instruction would be fine if you cloned all of the uses as well?

> > Also, won't being able to use tokens as parameters and returns completely break your analysis?  I mean, I can't imagine what sort of transformation would actually spontaneously extract a function like that, but if you were willing to rely on statements like that, you wouldn't need token types at all, because no plausible transformation is going to spontaneously insert intermediate SSA defs, either.

> 

> 

> I have a verifier rule against parameters or returns of token type except when inside of intrinsics.  Intrinsics, for obvious reasons, will have to make their token semantics quite clear.


Makes sense.

Okay, I may have just have misunderstood some of the restrictions you were proposing.  I have no further objections.


http://reviews.llvm.org/D11861