[PATCH] D15405: [EHPersonality] Add a new personality enum to represent langindPad of token type

[Philip Reames via llvm-commits]

reames added a comment.

In http://reviews.llvm.org/D15405#307272, @JosephTremoulet wrote:

> > Well, I don't think I want the new personality to be treated exactly like Unknown. I've looked at isNoOpWithoutInvoke when creating the patch, and I think in that case it should be treated as other known personalities and be safely removed
>
>
> Ah, ok.  That makes sense, though it means that "similar to Unknown, except that LandingPads have token type" isn't exactly correct as a description for Token_LP.  Since you're wanting both token-valued landingpads and to opt into isNoOpWithoutInvoke, I wonder if it wouldn't be better to go ahead and be specific about your runtime like the other non-Unknown enum values ... call it AzulJVM or whatever in the enum and use the name of an appropriate function in your runtime as the string.  If you want the code in SelectionDAG to be more general, you could add a property like usesTokenLandingPads(EHPersonality Pers) to EHPersonalities.h which returns true for AzulJVM, and have SelectionDAG query through that.


I agree with Joseph's point here, but might suggest a slightly different approach.  I don't see any value in having our specific personality function upstream.  (I don't really have any objection to having it upstream either.)

Would it make sense to add a personality function to our downstream tree and then add an upstream personality function for testing purposes which really is "unknown but with token return"?  The hook in isNoOpWithoutInvoke could then live in our local tree only.  Since we're probably going to want other similar hooks over time, maybe this makes sense.


http://reviews.llvm.org/D15405