similar to: [LLVMdev] RFC: New EH representation for MSVC compatibility

On Fri, May 15, 2015 at 5:27 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I like the way this sorts out with regard to funclet code generation. > It feels very natural for Windows EH, though obviously not as natural for > non-Windows targets and I think it is likely to block some optimizations > that are currently possible with those targets. > Right, it will

On Mon, May 18, 2015 at 8:40 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > > I want to have separate normal and exceptional codepaths > > I assume you at least mean that's what you'll be doing in Clang's initial > IR generation. Do you also mean to impose this as a restriction on other > IR generators, and as a property that IR transformations must

On Mon, May 18, 2015 at 12:03 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > Thanks for sending this out. We're looking forward to seeing this come > about, since we need funclet separation for LLILC as well (and I have > cycles to spend on it, if that would be helpful). > > > > Some questions about the new proposal: > > >

I think adding transitions to cleanupblocks on the normal execution path would be an optimization barrier. Most passes would see the cleanupblock instruction and run the other way. It's definitely appealing from the perspective of getting the smallest possible code, but I'm OK with having no more than two copies of everything in the finally block. I think with the addition of the

This example is pretty compelling, but I still think I want to limit the scope of this change to not include this feature. It's probably reasonable to hold onto the idea as future work, though. In the meantime, frontends can decide for themselves whether they want code size or stronger optimization of cleanups by doing early outlining or not. The only way we can hit the quadratic growth from

On Wed, Jul 1, 2015 at 2:10 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > I'd be interested in an updated summary as well, especially any thoughts > you have on when the various pieces might come online and where extra hands > could be helpful; we're eager to build our EH support in LLILC on top of > this. > A preliminary step was

On Wed, Jun 17, 2015 at 6:18 PM, Philip Reames <listmail at philipreames.com> wrote: > Since I haven't been following the thread closely, is there an updated > summary of the original proposal available? I know that various parts I > had concerns with (the unsplitable blocks for instance) got addressed, but > I'm having trouble tracking all the changes in discussion.

I’ve been experimenting with SEH handling in LLVM, and it seems like the unwind funclets generated by LLVM are much larger than those generated by Microsoft’s CL compiler. I used the following code as a test: void test() { MyClass x; externalFunction(); } Compiling with CL, the unwind funclet that destroys ‘x’ is just two lines of asm: lea rcx, QWORD PTR x$[rdx] jmp ??1MyClass@@QEAA at XZ

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

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

Thx again Evan for the review. Here's a new patch for the JIT in itself. The major changes are: 1) A JITMemoryManager now has a flag saying "I require to know the size of what you want to emit" 2) DwarfJITEmitter is augmented with GetSize* functions 3) JITEmitter::startFunction checks if the JITMemoryManager requires to know the size. If so, it computes it and gives it through the

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

i am sorry, i get this error: opt: /home/llvm/src/include/llvm/Support/CallSite.h:87: ValTy* llvm::CallSiteBase<FunTy, ValTy, UserTy, InstrTy, CallTy, InvokeTy, IterTy>::getCalledValue() const [with FunTy = const llvm::Function, ValTy = const llvm::Value, UserTy = const llvm::User, InstrTy = const llvm::Instruction, CallTy = const llvm::CallInst, InvokeTy = const llvm::InvokeInst, IterTy =

In the past people in #llvm suggested to me I should use landing pads instead of seh when it comes to Windows unless i really need seh. Looking at what gets generated win64 -gnu does use seh but calls the landing pad somehow, while win32 doesn't at all. It looks to me a custom win64 landing pad personality can also deal with things like Access Violation. Is there a way to make win32 also

Hi Bill, there is clearly a misunderstanding: either I am missing something essential or you are. To clear this up, I suggest you send me evil examples and I will show you how my scheme handles them (or doesn't handle them, if I am indeed failing to see something). > This is the code that G++ generates from the example in my proposal: ... > If the call to __Z3foov throws, we need to

Hi neda 8664, > I want to find memory dependency between CallInst instruction and other. So i > used the following code: > > > > / AliasAnalysis &AA=getAnalysis<AliasAnalysis>();/ > > /*if* (isa< StoreInst >(inst1)){ / > > // // /*if* (isa<CallInst>(inst2)) / /{/ > > / CallInst *call_inst2= dyn_cast<CallInst>(inst2); /

Hi all, I want to find memory dependency between CallInst instruction and other. So i used the following code: * AliasAnalysis &AA=getAnalysis<AliasAnalysis>();* * if(isa<StoreInst>(inst1)){* * ** **if(isa<CallInst>(inst2))**{* * CallInst *call_inst2= dyn_cast<CallInst>(inst2); * * if(AA.getModRefInfo(inst1,call_inst2)==mod)**{* *

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Bringing this back up for discussion on handling exceptions. According to the inalloca design <https://llvm.org/docs/InAlloca.html>, there should be a stackrestore after an invoke in both the non-exceptional and exceptional case (that doesn't seem to be happening in some cases as we've seen, but that's beside the point). Does it make sense to model a preallocated call as

On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-15 18:37:58 -0400, Reid Kleckner said: > > After a long tale of sorrow and woe, my colleagues and I stand here >> before you defeated. The Itanium EH representation is not amenable to >> implementing MSVC-compatible exceptions. We need a new representation that >> preserves