[PATCH] D11861: [IR] Add token types

[David Majnemer via llvm-commits]

majnemer added a comment.

In http://reviews.llvm.org/D11861#224058, @rjmccall wrote:

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


Oh, for sure :)

> Still, interesting; do you know if that's intentional?


No idea.  Pointers to `opaque` make sense but we forbid loading them.
The only real use-case that I can imagine is for special, magick, intrinsics.

> 

> 

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


Yes, it is totally fine to clone a `BasicBlock` wholesale where the token producer feeds into the user.

> 

> 

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


Great, thanks!


http://reviews.llvm.org/D11861