similar to: [LLVMdev] Location of cppeh outlining tests

Hi, Have any decisions been made on where to put executable WinEH tests? Wherever they go, would it be helpful if I were to add some C++EH and/or SEH tests pulled from MSVC's test suite, since compatibility is the goal here? Thanks -Joseph From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Reid Kleckner Sent: Tuesday, May 19, 2015 5:56 PM To: Kaylor,

I think we should make a new svn repository for these. test-suite is the logical place, but it's way too bloated and has too much Unix specific baggage. I'd really like to have something that just uses lit, can be checked out into projects, and can be run as part of check-all, like the compiler-rt execution test suite. My suggestion is to call it 'execution-tests', and we can

On 2017-04-26 19:56, Eric Christopher wrote: > That's really weird. I'm quite surprised that the entry block was moved > so much later in the function but haven't had a chance to look more at > it. Probably want to take a look and find out where that's happening and > why. From irc, thegameg helped me find the -enable-shrink-wrap=false, which "fixes" this,

Have got anything started with the dispatchblock plan? From: Reid Kleckner [mailto:rnk at google.com] Sent: Wednesday, May 13, 2015 1:15 PM To: Kaylor, Andrew Cc: David Majnemer <david.majnemer at gmail.com> (david.majnemer at gmail.com); LLVM Developers Mailing List Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling On Wed, May 13, 2015 at 11:03 AM, Kaylor, Andrew

On Tue, May 19, 2015 at 2:16 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > What follows is primarily addressed to Reid and David, but since it some > of it is relevant to the Windows exception handling proposal under > discussion, I thought I should copy the LLVMDev distribution list. Anyone > interested should feel free to jump in and discuss. > > > >

I made some progress this afternoon. I now have a set of changes in my local sandbox that allows clang to pass all of the tests in the suite I’ve been using to exercise this code. How do you feel about working these changes into trunk to establish a working baseline, even knowing that parts of this are going to be redesigned? -Andy From: Reid Kleckner [mailto:rnk at google.com] Sent:

Just as an off-the-cuff idea that I haven’t thought through at all, what would you think of the possibility of replacing this: %12 = call i32 @llvm.eh.typeid.for(i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0 to i8*)) %matches7 = icmp eq i32 %sel6, %12 with this: %matches7 = call i32 @llvm.eh.cmp.selector(i32 %sel6, i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0

What follows is primarily addressed to Reid and David, but since it some of it is relevant to the Windows exception handling proposal under discussion, I thought I should copy the LLVMDev distribution list. Anyone interested should feel free to jump in and discuss. My primary purpose here is to talk about what I'm working on so that anyone who is also working on the same things can let me

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 frame, I thought about it in terms of "let's allocate something at a fixed offset from ebp to keep things simple". That line of thinking suggested that we needed this thing to be fundamentally different

Is this example what you had in mind? void f() { int *p = get_p(); use_p(p); try { may_throw(p); } catch (int) { // don't need p } use_p(p); } The idea is that because p is not modified or used within the catch region (the funclet), it can live in a callee-saved register across the whole function. That is true, it is possible, but I don't think it fits very well in

Hi, All I am trying to implement a llvm backend. But I encountered the following problem when running the backend: "Fatal error: error in backend: WinEH not implemented for this target" This error is triggered by function processFunctionBeforeFrameFinalized() defined in class TargetFrameLowering. Can anyone help? Thanks a lot! Zhiguo [cid:image001.jpg at 01D50970.C9344210]

https://llvm.org/docs/ExceptionHandling.html#wineh > No variables live in to or out of the funclet can be allocated in registers. I don't think this is quite true. though it might be a useful simplification. Obviously it is true for volatile registers, but I believe the funclet receives a CONTEXT with the nonvolatiles restored. Obviously cumbersome to access, but it lets you enregister

On Wed, Jan 11, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Can you elaborate why? I’m curious. > The con of proposal c was that many passes would need to learn about many region intrinsics. With tokens, you only need to teach all passes about tokens, which they should already know about because WinEH and other things use them. With tokens, we can add as

Hi, On Thu, 28 Jul 2016 09:32:18 -0700 Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think David and I are probably the most familiar with how WinEH works in > LLVM, but I don't think either of us has time to prepare a talk for the dev > meeting. I'm trying to prepare a talk on supporting the MS debug info > format in LLVM this year. That said,

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

> On Jan 12, 2017, at 5:02 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On 01/12/2017 06:20 PM, Reid Kleckner via llvm-dev wrote: > >> On Wed, Jan 11, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >> Can you elaborate why? I’m curious. >> >> The con of proposal c was that many passes would need

I think David and I are probably the most familiar with how WinEH works in LLVM, but I don't think either of us has time to prepare a talk for the dev meeting. I'm trying to prepare a talk on supporting the MS debug info format in LLVM this year. That said, I'll definitely have time to answer questions in person. It might be worth setting up a BoF to schedule some time We gave a 30m

> 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

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

I've been looking at compilation time issues in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions. For one thing, the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don't use the