search for: getexceptionpointerregist

...ing with a personality using catchpads/cleanuppads instead of landingpads. 2) Since you're not actually using the landingpad's exception selector 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 s...

...ing with a personality using catchpads/cleanuppads instead of landingpads. 2) Since you're not actually using the landingpad's exception selector 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 s...

...cular target, what need to be done. After doing some investigation, I can think of the following items with questions: - CFI directives: This is for .eh_frame section. Basically all the targets insert CFI directives in FrameLowering, but I am not sure exactly when/where I should do so. - getExceptionPointerRegister and getExceptionSelectorRegister: TargetLowering subclass should implement both functions. The former specifies the register used to pass the exception object to the landing pad (or catch clause), and the latter specifies the register used to pass the typeid object to the landing pad. Where...

...contains "throw X"). So normally the directives are emitted in the prologue when the registers actually get saved. Sometimes all in a bunch, sometimes interspersed with the saves, but it usually doesn't matter which. As you've discovered that happens in XYZFrameLowering > - getExceptionPointerRegister and getExceptionSelectorRegister: > > TargetLowering subclass should implement both functions. The former > specifies the register used to pass the exception object to the landing pad > (or catch clause), and the latter specifies the register used to pass the > typeid object to...

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

Hi Scott, Sorry for the late reply, I was out of office during the holidays. 1. A def node can reach either a use node, or another def node. In the highlighted phi node (p3224), the def (d3225) reaches another def (1598) in statement (s1597), that’s why it’s needed. 2. The reason why the def of R11 in s1578 is not connected directly to the use in s1725 is that there may be an intervening