[PATCH] D11861: [IR] Add token types

[David Majnemer via llvm-commits]

majnemer added a comment.

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

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


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

  %X = type opaque
  
  declare %X @g()
  
  declare %X @h()
  
  declare void @i(%X)
  
  define %X @f(i1 %A) {
  entry:
    br i1 %A, label %bb1, label %bb2
  
  bb1:                                              ; preds = %entry
    %V1 = call %X @h()
    br label %bb
  
  bb2:                                              ; preds = %entry
    %V2 = call %X @g()
    br label %bb
  
  bb:                                               ; preds = %bb2, %bb1
    %P = phi %X [ %V1, %bb1 ], [ %V2, %bb2 ]
    ret %X %P
  }



> 

> 

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


That's a fair assessment.

> 

> 

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


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.

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


http://reviews.llvm.org/D11861