search for: ehpersonalities

...tatepoint 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 reality I doubt you'd be opening a floodgate here). Yes, we don’t neither...

(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

...tatepoint 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 reality I doubt you'd be opening a floodgate here). 3) Maybe the default...

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