Should personality functions actually be functions

(Moving to LLVM-dev). I hope thats ok to just move the conversation over from commits.

To summarise, selection DAG crashes if personality functions are not actually functions. This conversation is to try work out if that is a restriction we want to document in LangRef, or (as David B suggests), we should allow opaque values to be personality functions. I don’t actually know EH code at all, so I don’t know what the right answer is.

Yep, makes sense.

Yeah, this is a little vague. Considering the code in SelectionDAGBuilder will always crash if we have a non-Function*, I believe that means we could never have actually codegen-ed any of the code I had to fix in test cases.

So i actually know nothing about this either. When i originally found the crash, personality functions were still on the LandingPadInst itself.

I agree that typically its fine to be able to use opaque values. Unless we actually have to introspect the personality Function*, eg, for calling conventions, then I think its fine to allow any value. In fact, it looks like classifyEHPersonality was written to support this.

Pete

+Majnemer, since he’s been mucking about with this stuff recently

I think the easiest path forward is to keep getPersonalityFn returning a Constant and make this a dyn_cast. I’m halfway done with fixing it.

I think the easiest path forward is to keep getPersonalityFn returning a Constant and make this a dyn_cast.

Thats totally fine with me.

I’m halfway done with fixing it.

Thats great, thanks!

Pete