[PATCH] D11861: [IR] Add token types

[John McCall via llvm-commits]

rjmccall added a comment.

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

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

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


http://reviews.llvm.org/D11861