[PATCH] D11861: [IR] Add token types

[John McCall via llvm-commits]

rjmccall added a comment.

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

> `opaque` can be inside of aggregates, function types can have `opaque` as their return type.


Okay, but the corresponding aggregate/function type isn't usable as an aggregate/function: you can't GEP into the aggregate, and you can't call the function.  My point is that arbitrary code does not have to worry about these types existing.

> `LabelTy` can actually be used in places outside of successor lists and `blockaddress`.  However, things go badly if the `BasicBlock` referred to be the label becomes unreachable as we expect all the non-successor uses to be `blockaddress`.


So, to me, that sounds like you *can't* use LabelTy in other places, but we just haven't formalized that restriction and enforced it in the verifier.

> > Not based on their uses, I don't think.  In fact, I don't remember there being any instructions that can't be cloned at all — even indirectbr is only *dangerous* to clone, and only because it tends to cause catastrophic use-list scaling problems.  The closest thing I can think of is that you can't move an indirectbr (or any of its blockaddress destinations) to a different function.

> 

> 

> The `noduplicate` function attribute imbues `call`s and `invoke`s may not be cloned: http://llvm.org/docs/LangRef.html#function-attributes


Ah, interesting.

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

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.


http://reviews.llvm.org/D11861