search for: get_capture_block

...to call std::terminate when cleanup dtors throw. The current representation for Itanium is inefficient. As a strawman, I propose making @__clang_call_terminate an intrinsic: … That sounds like a good starting point. > Chandler expressed strong concerns about this design, however, as @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once you add this intrinsic, we *have* to do frame layout of @_Z13do_some_thingRi *before* we can emit code for all the callers of @llvm.eh.get_capture_block. Today, this is easy, because module order defines emission order, but in the great glorious future,...

...pass that transforms the above IR to this: %struct.do_some_thing.captureblock = type { %class.Outer, %class.Middle, %class.Inner, %i32* } ; Uncaught exception cleanup for lpad, lpad1 and lpad4 define void @do_some_thing_cleanup0(i8* %eh_ptrs, i8* %rbp) #0 { entry: %capture.block = call @llvm.eh.get_capture_block(@_Z13do_some_thingRi , %rbp) %outer = getelementptr inbounds %struct.do_some_this.captureblock* %capture.block, i32 0, i32 0 invoke void @_ZN5OuterD1Ev(%class.Outer* %outer) to label %invoke.cont unwind label %terminate.lpad invoke.cont: ret void terminate.lpad:...

...ady the status quo for SjLj exceptions, which introduce a number of uninlinable intrinsic calls (although maybe SjLj is a bad precedent :). > > The way I see it, it's just a question of how much frame layout information you want to teach CodeGen to save. If we add the set_capture_block / get_capture_block intrinsics, then we only need to save the frame offset of *one* alloca. This is easy, we can throw it into a side table on MachineModuleInfo. If we don't go this way, we need to save just the right amount of CodeGen state to get stack offsets in some other function. This is the only part that...

...I want to do this on LLVM IR during CodeGenPrepare. The major challenge that outlining anywhere presents is that now the outlined code has to "know" something about the frame layout of the function it was outlined from in order to access local variables. I think we can add `i8* @llvm.eh.get_capture_block(i8* %function, i8* %parent_rbp)` and `void @llvm.eh.set_capture_block(i8* %captures)` intrinsics to make this work. Any SSA values or allocas captured by the outlined landing pad code will be demoted to memory and stored in the capture block, and the layout will be encoded in a struct used by the o...

...status quo for SjLj exceptions, which introduce a number of uninlinable intrinsic calls (although maybe SjLj is a bad precedent :). >> >> The way I see it, it's just a question of how much frame layout information you want to teach CodeGen to save. If we add the set_capture_block / get_capture_block intrinsics, then we only need to save the frame offset of *one* alloca. This is easy, we can throw it into a side table on MachineModuleInfo. If we don't go this way, we need to save just the right amount of CodeGen state to get stack offsets in some other function. > > This is the only...

...LVM IR during CodeGenPrepare. > > > > The major challenge that outlining anywhere presents is that now the outlined code has to "know" something about the frame layout of the function it was outlined from in order to access local variables. I think we can add `i8* @llvm.eh.get_capture_block(i8* %function, i8* %parent_rbp)` and `void @llvm.eh.set_capture_block(i8* %captures)` intrinsics to make this work. Any SSA values or allocas captured by the outlined landing pad code will be demoted to memory and stored in the capture block, and the layout will be encoded in a struct used by the o...

...to call std::terminate when cleanup dtors throw. The current representation for Itanium is inefficient. As a strawman, I propose making @__clang_call_terminate an intrinsic: … That sounds like a good starting point. > Chandler expressed strong concerns about this design, however, as @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once you add this intrinsic, we *have* to do frame layout of @_Z13do_some_thingRi *before* we can emit code for all the callers of @llvm.eh.get_capture_block. Today, this is easy, because module order defines emission order, but in the great glorious future,...

...I want to do this on LLVM IR during CodeGenPrepare. The major challenge that outlining anywhere presents is that now the outlined code has to "know" something about the frame layout of the function it was outlined from in order to access local variables. I think we can add `i8* @llvm.eh.get_capture_block(i8* %function, i8* %parent_rbp)` and `void @llvm.eh.set_capture_block(i8* %captures)` intrinsics to make this work. Any SSA values or allocas captured by the outlined landing pad code will be demoted to memory and stored in the capture block, and the layout will be encoded in a struct used by the o...

Hi Reid, I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood. I’m still trying to get up to speed on what is and is

...wman, I propose making @__clang_call_terminate an intrinsic: >> >> … >> >> >> >> That sounds like a good starting point. >> >> >> >> >> >> > Chandler expressed strong concerns about this design, however, as >> @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once you >> add this intrinsic, we *have* to do frame layout of @_Z13do_some_thingRi >> *before* we can emit code for all the callers of >> @llvm.eh.get_capture_block. Today, this is easy, because module order >> defines emission order...