[PATCH] D11861: [IR] Add token types

[David Majnemer via llvm-commits]

majnemer added a comment.

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

> In http://reviews.llvm.org/D11861#223512, @majnemer wrote:
>
> > In http://reviews.llvm.org/D11861#223510, @rjmccall wrote:
> >
> > > Could you clarify what, exactly, it is about your personality routine that requires a single exit to correspond to a single entry?  Is that on a runtime level or just on a backend-lowering level?  I am having trouble imagining what on a runtime level would rely on sniffing the address of the return instruction from the cleanup routine, but I am also having trouble imagining what it is about lowering that justifies such an incredibly invasive change to IR.  You're introducing a type of "value" that instantly becomes a massive exception to every single standard rule about values.  You can't put them in memory, you can't put them in PHIs, you can't put them in selects, you can't propagate them into or out of functions, you can't clone an instruction that contains a use, and I'm sure there are a dozen other difficulties.
> >
> >
> > There are already values which may not be PHI'd or stuck in selects: `LabelTy`, `MetadataTy`, `FunctionTy`
> >  There are also values which may not be loaded or stores to in memory: `opaque` structures, `MetadataTy`, `FunctionTy`, `LabelTy`
>
>
> There are no values of FunctionTy at all; I think that's true of `opaque` as well, but maybe you can make an undef.


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

>   MetadataTy makes no pretense at all to being an ordinary value; metadata are legal in exactly two positions (operands of other metadata, and a special location on instructions).  LabelTy is only legal in successor lists, and as far as I've ever been able to tell, there's not really any good reason for it exist, or indeed basic blocks to be Values at all; you could certainly implement blockaddress without that.


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

> 

> 

> > There are also values which cannot be passed into or out of functions

> 

> 

> Beyond the above values?

> 

> > and instructions which may not be cloned.

> 

> 

> 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

> 

> 

> > > This seems like a wildly general attempt at a solution, but its restrictions will probably prevent it from being useful for anything other than your EH problem, and I am very concerned that you will eventually discover that it isn't even all that useful or important for your EH problem, leaving this as an unwanted fruit simply bit-rotting on the vine.

> 

> > 

> 

> > 

> 

> > It was, in fact, originally designed to handle a JIT deopt problem.  I am merely reusing it for my EH purposes.

> 

> 

> This proposal is still under design; it's changed multiple times in this very thread.  It's at least not obvious to me that it still satisfies everyone else's needs with these changes, because I don't understand anyone else's needs, because they seem to me to be very hand-wavey.

> 

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


http://reviews.llvm.org/D11861