search for: winehprepare

Yes, it seems like WinEHPrepare should always be able to move landing pad code to somewhere appropriate. Even if there's some involved code to handle the cases that force #1, it's great that the complexity is contained in WinEHPrepare. I'm still confused about the apparent lack of constraints after WinEHPrepare. Ca...

Hi Reid and David, I just wanted to give you a heads up that I'm currently working on a problem where the WinEHPrepare outlining code stumbles and asserts while cloning code that references extracted landing pad values via PHI nodes that are in intermediate blocks that aren't being cloned. The test I'm looking at fails with an assertion claiming that llvm.eh.begincatch was called twice inside a handler. I...

...lopers Mailing List Subject: Re: [WinEH] Cloning blocks that reference non-cloned PHI nodes Sounds reasonable. Honestly, we've been having some serious whiteboard discussions about how to get out of doing all this selector pattern matching. I think that's basically the most fragile part of winehprepare, and if we can add some new constructs that wrap that up in something opaque to mid-level passes, that would be great. Unfortunately, I haven't really been able to get enough consensus to write something down. If I can't convince my coworkers that we need a new construct in person, there...

...ndle associated with them. This causes the Windows Exception Handling Preparation Pass to drop all the instructions within the exception handler starting from the PGO instrumentation call, and replace them with 'unreachable'. This is being done by the function removeImplausibleInstructions (WinEHPrepare.cpp). A simple reproducer of the problem shown here which will lead to incorrect code on the method test::run(). In this example, the virtual function called from within the exception handler triggers the bug when using -fprofile-generate. #include <stdexcept> #inclu...

...the rest to SlotIndex.h. Introduce a new container class in SlotIndex.h that will extract the map between machine instructions and slot indexes from the SlotIndexes pass and remove the dependency on the pass from MachineBasicBlock's print method. - WinEHFuncInfo - Either move parseEHInfo from WinEHPrepare.cpp to new file WinEHFuncInfo.cpp or move the declaration of parseEHInfo from WinEHFuncInfo.h to a new header WinEHPrepare.h - Get rid of several unused #includes in MachineIR cpp files that include passes. After that it should be possible to move the Machine IR files out of CodeGen without them...

...o SlotIndex.h. Introduce a new container class in SlotIndex.h that will extract the map > between machine instructions and slot indexes from the SlotIndexes pass and remove the dependency on the pass from MachineBasicBlock's print method. > - WinEHFuncInfo - Either move parseEHInfo from WinEHPrepare.cpp to new file WinEHFuncInfo.cpp or move the declaration of parseEHInfo from WinEHFuncInfo.h > to a new header WinEHPrepare.h > - Get rid of several unused #includes in MachineIR cpp files that include passes. > > After that it should be possible to move the Machine IR files out of...

...them. This causes the Windows Exception Handling > Preparation Pass to drop all the instructions within the exception handler > starting from the PGO instrumentation call, and replace them with > 'unreachable'. This is being done by the function > removeImplausibleInstructions (WinEHPrepare.cpp). > > A simple reproducer of the problem shown here which will lead to > incorrect code on the method test::run(). In this example, the virtual > function called from within the exception handler triggers the bug when > using -fprofile-generate. > > #include <s...

Hi David: >> How do you deal with basic blocks which appear to be used by multiple parts >> of the coroutine? We handled this in WinEHPrepare by cloning any BBs which >> were shared. I experimented with several approaches, but, cloning ended up being the simplest and most reliable. Suspend points express three different control flows that can happen at the suspend point: a suspension (default), resumption (0) and destruction (1)....

...ndex.h. Introduce a new container class in SlotIndex.h that will extract the map >> between machine instructions and slot indexes from the SlotIndexes pass and remove the dependency on the pass from MachineBasicBlock's print method. >> - WinEHFuncInfo - Either move parseEHInfo from WinEHPrepare.cpp to new file WinEHFuncInfo.cpp or move the declaration of parseEHInfo from WinEHFuncInfo.h >> to a new header WinEHPrepare.h >> - Get rid of several unused #includes in MachineIR cpp files that include passes. >> >> After that it should be possible to move the Machine I...

...pare passes. For the majority of platforms the intrinsics will be directly mapped to the existing function calls during one of the CodeGen prepare passes. For MSVC-environment Windows targets there is no equivalent function call to be made, but these intrinsics will be extremely useful during the WinEHPrepare pass as a means of identifying the limits of catch-specific code. If there is a reason why I should not introduce intrinsics for this purpose, please give me feedback now. Otherwise, I'm going to begin work on a patch to support this in the back end with the expectation that a corresponding c...

Hi, This page http://clang.llvm.org/docs/MSVCCompatibility.html says clang-cl supports C ++ exceptions, but I cannot compile code with simple try{}catch{} error : cannot compile this throw expression yet What am i doing wrong? -- WBR, Arkady Shapkin aka Dragon -------------- next part -------------- An HTML attachment was scrubbed... URL:

I've been working recently to get the following test case working for an x86_64-pc-windows-msvc target. void test1() { try { try { throw 1; } catch(...) { throw; } } catch (...) { } } I committed a patch earlier in the week to get the WinEHPrepare pass to produce IR that I thought was sufficient, but as I mentioned in the review I was still seeing runtime errors when executing a program compiled with this code. I have since figured out why the program crashes at runtime, but fixing it is going to be a bit tricky. It has to do with some wri...

> We'd have to hoist a + b to somewhere that dominates L1 and L2. I think the only BB in your program that dominates is the entry block I don't follow. What path do you see from entry to either L1 or L2 that doesn't pass through the indirectbr? In order to reach either L1 or L2, the call to maybe_throw() must raise an exception (else we'd return 0 from foo), the exception must

...already have something like this for cleanupblocks because the resume target and unwind label of the cleanupblock must match. It isn't as strong as having a reference to the catchblock itself, because tail merging could kick in like you mention. Undoing this would be and currently is the job of WinEHPrepare. I guess I felt like the extra representational complexity wasn't worth the confidence that it would buy us. > - What is the plan for cleanup/__finally code that may be executed on > either normal paths or EH paths? One could imagine a number of options > here: > > + require t...

On Wed, Mar 4, 2015 at 12:36 AM, John McCall <rjmccall at apple.com> wrote: > > On Mar 3, 2015, at 2:25 PM, Reid Kleckner <rnk at google.com> wrote: > > > > I realized that WinEH preparation can probably be a lot less invasive > than it is currently. > > > > Initially, when I was thinking about recovering the address of an object > in a parent stack

...l, label %finally.unwind, label %finally.normal finally.unwind: unwind from label %cleanupblock finally.normal: ret void With two reachability checks we can see that cleanup, finally, and finally.unwind are the only BBs in the finally funclet, and only finally is shared. We can duplicate it in WinEHPrepare and fix up the CFG to reflect that. I don't think the quadratic case is possible, even in a nested case like: try { try { f(); } finally { do_finally(1); } } finally { do_finally(2); } We'll end up with four calls to do_finally in this example. Does that seem OK? If that...

...one of the more obscure corner cases. Also, __finally is pretty rare, so it's not too crazy to teach the inliner how to undo framerecover and let the optimization fall out that way. > > tail merging could kick in like you mention. Undoing this would be and > currently is the job of WinEHPrepare. I guess I felt like the extra > representational complexity wasn't worth the confidence that it would buy us > > For one, it seems counterproductive to let tail merge think it can kick in > when it's doomed to be undone. > I'm only saying that the tail merging is legal,...

...ind: > > unwind from label %cleanupblock > > finally.normal: > > ret void > > > > With two reachability checks we can see that cleanup, finally, and > finally.unwind are the only BBs in the finally funclet, and only finally is > shared. We can duplicate it in WinEHPrepare and fix up the CFG to reflect > that. I don't think the quadratic case is possible, even in a nested case > like: > > > > try { > > try { > > f(); > } finally { > > do_finally(1); > } > > } finally { > > do_finally(2); > }...

...assume the filter can run during any potentially throwing function call. MSVC EH implementation strategy ---------------------------------------------- Skim this if you just need the semantics of the representation above, and not the implementation details. The new EH block representation allows WinEHPrepare to get a lot simpler. EH blocks should now look a lot more familiar, they are single entry, multi-exit regions of code. This is exactly equivalent to a function, and we can call them funclets. The plan is to generate code for the parent function first, skipping all exceptional blocks, and then gene...

Hi all: I've included below a brief description of coroutine related optimization passes and some questions/thoughts related to them. Looking forward to your feedback, comments and questions. Thank you! Roadmap: ======== 1) Get agreement on coroutine representation and overall direction. .. repeat 1) until happy http://lists.llvm.org/pipermail/llvm-dev/2016-June/100838.html (Initial)