search for: sjljehprepare

When testing with LLVM 3.0 I noticed a crash in LLC with a test case we are running. After examining the source, I found that the crash coming from SjLjEHPrepare.cpp, specifically from "ReplaceLandingPadVal". I can explain about the crash if needed, but I will omit that for now. Testing with and LLC built from the top of trunk showed no LLC crash, and the code in SjLhEHPrepare.cpp has been very much changed. The comment in revision 142800 indica...

...ption > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside, LowerInvoke has an option for using SJLJ exception handling, > but that option appears to be unused and replaced > by lib/CodeGen/SjLjEHPrepare.cpp.) > On that topic, should LowerInvoke's "-enable-correct-eh-support" option be removed, since it appears to be unused? If so, I can prepare a patch. This option lowers exception handling to setjmp/longjmp, but it uses a variable called "llvm.sjljeh.jblist" for the...

...k.be> wrote: > > Actually, there's another —even more fundamental— problem: the longjmp > will always restore the non-volatile registers to the contents they had > at the start of the try-block, which is not what LLVM expects when > entering an SEH-based landing pad. > The SjLjEHPrepare pass tries to deal with this by demoting all values live across EH edges to the stack. This should also eliminate those phis from landingpad blocks. Check out TargetPassConfig::addPassesToHandleExceptions() and make sure you run that pass. -------------- next part -------------- An HTML attachment...

Hello Clang- and LLVM-Experts, I was not sure which list is the right one, so I tried both - sorry for any inconvenient >o< Lately I was working a lot with exceptions under Windows and especially with the Clang compiler. Out of curiosity I came along "Exception Handling in LLVM" and tried to understand the SJLJ exception handling. At first glance this made total sense to me! Store

Jonas Maebe via llvm-dev wrote: > Then, I tried the following: > a) if the longjmp for the try-block is taken (i.e., the setjmp right > before the try-block returns a non-zero value), jump to the landingpad BBL. > > -> Problem: LLVM does not allow regular jump edges to landingpad BBLs > > b) since the landingpad is empty anyway and falls through into the next > BBL

> On Nov 17, 2014, at 5:50 PM, Reid Kleckner <rnk at google.com> wrote: > > On Mon, Nov 17, 2014 at 5:22 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it

On Jul 22, 2011, at 11:52 PM, Cameron Zwarich wrote: > On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > >> On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: >> >>> // Restrictions: >>> >>> There are several new invariants which will be enforced by the verifier: >>> >>> 1. A landing pad block is a basic block which is

...t local variables need to be in the capture block? If the front-end needs to decide that, is that something that fits easily into how clang works? > > The capture block would be a boring old LLVM struct with a type created during CodeGenPrepare. > > I'm imagining a pass similar to SjLjEHPrepare that: > - Identifies all bbs reachable from landing pads > - Identifies all SSA values live in those bbs > - Demote all non-alloca SSA values to allocas (DemoteRegToMem, like sjlj) > - Combine all allocas used in landing pad bbs into a single LLVM alloca with a new combined struct type...

On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > >> // Restrictions: >> >> There are several new invariants which will be enforced by the verifier: >> >> 1. A landing pad block is a basic block which is the unwind destination of an >> invoke instruction. >> 2. A landing pad block

...by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look like "landingpad ... catch label %filter0 ..." instead of "landingpad ... catch ... @filter_func0 ...". There would be a backend pass similar to SjLjEHPrepare that would outline the filter function and cleanup actions. Once we do the outlining, there is no turning back, because the outlined function has to know something about the stack layout of the parent function. If the parent function is inlined, we would have to duplicate the filter function along...

> On Feb 2, 2015, at 4:53 PM, Reid Kleckner <rnk at google.com> wrote: > This seems reasonable to me. Adding John explicitly… Thanks, Reid. Andy, I understand why Windows EH needs custom lowering here, and using intrinsics seems like a fine approach, but I don’t understand why you’re proposing changing the Itanium code generation pattern. There’s no reason for backends to have

The PNaCl project has implemented various IR simplification passes that simplify LLVM IR by lowering complex features to simpler features. We'd like to upstream some of these IR passes to LLVM. We'd like to explore if this acceptable, and if so, how we should go about doing this. The immediate reason is that Emscripten is reusing PNaCl's IR passes for its new "fastcomp"

...by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look like "landingpad ... catch label %filter0 ..." instead of "landingpad ... catch ... @filter_func0 ...". There would be a backend pass similar to SjLjEHPrepare that would outline the filter function and cleanup actions. Once we do the outlining, there is no turning back, because the outlined function has to know something about the stack layout of the parent function. If the parent function is inlined, we would have to duplicate the filter function along...

...erts build llvm[2]: Compiling ScoreboardHazardRecognizer.cpp for Release+Asserts build llvm[2]: Compiling ShadowStackGC.cpp for Release+Asserts build llvm[2]: Compiling ShadowStackGCLowering.cpp for Release+Asserts build llvm[2]: Compiling ShrinkWrap.cpp for Release+Asserts build llvm[2]: Compiling SjLjEHPrepare.cpp for Release+Asserts build llvm[2]: Compiling SlotIndexes.cpp for Release+Asserts build llvm[2]: Compiling SpillPlacement.cpp for Release+Asserts build llvm[2]: Compiling SplitKit.cpp for Release+Asserts build llvm[2]: Compiling StackColoring.cpp for Release+Asserts build llvm[2]: Compiling Stac...