search for: visitlandingpad

...ng landingpads with exception pointers / exception selectors to update their code and add themselves to Analysis/EHPersonalities.h, similar to how #2 would require adding your personality, so it seems more disruptive if conceptually a touch cleaner than #2. 4) Explicitly checking for token type in visitLandingPad as you suggest sounds okay to me as a pragmatic approach, too. I'd probably lean toward #2 as being the least disruptive and most explicit/straightforward about the personality's expectations, but I'm curious what others think. Thanks -Joseph From: Chen Li [mailto:meloli87 at gmail.c...

...somewhat independent and pre-existing issue, and in reality I doubt you'd be opening a floodgate here). Yes, we don’t neither the exception selector nor the exception pointer. I’ve taken a similar approach as #2 you suggested, but instead of modifying the personality, I directly add a check in visitLandingPad to see if landingpad is token type. If so, don’t create DAG node for selector and exception pointer even if TLI.getExceptionPointerRegister and TLI.getExceptionSelectorRegister are not zero or NoRegister. I think this works correctly and I’ve passed all the tests I have. I plan to check this in as...

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