search for: exitlandingpad

...mpiler that similarly used stand-in code to model control flow effected by the runtime/unwinder, and we had these issues with code motion. Our system was closed enough that we could just have the affected optimizations check for the relevant opcodes (we were doing the equivalent of using a special exitlandingpad terminator instead of indirectbr) and avoid pushing code across them; I don't know if a similar approach is appropriate in LLVM, or if there is (or should be) a way to annotate the block to indicate that it's one of these cases and new code inserted there would get skipped over at run-time,...

...mpiler that similarly used stand-in code to model control flow effected by the runtime/unwinder, and we had these issues with code motion. Our system was closed enough that we could just have the affected optimizations check for the relevant opcodes (we were doing the equivalent of using a special exitlandingpad terminator instead of indirectbr) and avoid pushing code across them; I don't know if a similar approach is appropriate in LLVM, or if there is (or should be) a way to annotate the block to indicate that it's one of these cases and new code inserted there would get skipped over at run-time,...

Ah, ok. So if the outliner sees non-dispatch code in the landing pad area, it can find/create somewhere to put it and an appropriate eh.actions annotation to get an EH table generated that will ensure it gets executed appropriately at run-time (in this example, perform the add before invoking either handler); is that more or less the idea? That makes sense, thanks. I have the same question