search for: ehperson

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll want to look at the handling of the @llvm.eh.exceptionpointer intrinsic that's used with catchpads and basically do the same thing with landingpads. Thanks -Joseph Fro...

..., 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 >> >> (especially with pointer bitcasts (which will go away, eventually) - if I have a global variable I've put some executable bytes in and I cast a pointer to that global variable to a pointer to a function, I would expect that should be in...

...or nor, if I understand " This is enough to support the gc.statepoint work " correctly, its exception pointer, it's possible that TLI.getExceptionPointerRegister and TLI.getExceptionSelectorRegister should be returning NoRegister for your personality. That would require modifying the EHPersonality enum and corresponding string matching in Analysis/EHPersonalities.h to recognize your personality, but I think that would be fine (it highlights a potential scaling issue if we add lots of targets that each need this, but that's a somewhat independent and pre-existing issue, and in realit...

...ly OpenVMS-specific needs that others won't care about). We've noted that gcc seems to generate better asynchronous unwind info and has the companion -fasynchronous-unwind-tables.  clang just maps it to -funwind-tables. We've also noted that Reid and company have nicely added Analysis/EHPersonalities.h along with a "isAsynchronousEHPersonality" function for MSVC personality routines. I'll post an RFC in January to get some feedback, but wanted to know if others have out-of-tree unwind changes in this area.  Perhaps they might be helpful to us. John

> On Dec 1, 2015, at 11:14 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > While we support 'opaque' types nested within struct types, they are not exactly battle tested: > > $ cat t.ll > %opaque_ty = type opaque > > %struct_ty = type { i32, %opaque_ty } > > define %struct_ty @f(%struct_ty* %p) { > %load = load %struct_ty,