search for: funclet

...when building for Windows. The problem occurs when the value profiling inserts function calls into exception handling blocks. The instrumentation inserts value profiling intrinsic calls, and these are subsequently lowered into target library calls. However, these library calls do not get a funclet operand bundle 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 removeImplausibleIns...

I think the simplest, most complete, short term fix, would be to call llvm::colorEHFunclets, and to have the relevant instrumentation passes apply the appropriate funclet bundle when inserting function calls. It's not elegant because it means every simple instrumentation pass that inserts regular function calls (ASan, TSan, MSan, instrprof, etc) needs to be funclet-aware. But, it wil...

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...

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 coloring in...

I've modified llvm to emit vc++ compatible SEH structures for my personality on x86/Windows and my handler works fine, but the only thing I can't figure out is how to call these funclets, they look like: Catch: "?catch$3@?0?m3 at 4HA": LBB4_3: # %BasicBlock26 pushl %ebp pushl %eax addl $12, %ebp movl %esp, -28(%ebp) movl $LBB4_5, %eax addl $4, %esp popl %ebp retl # CATCHRET cleanup: "?dtor$2@?0?...

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 the...

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 our current model and CFG. Given that it doesn't fit the model, I don't think it's helpful to try to explain this in the documentation. The docum...

...], [false, %cont] call void @do_finally() br i1 %abnormal, 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...

...your suggestion to have the normal path branch into the finally > (after the cleanupblock) and back out, it delays the duplication to EH > preparation, but still requires duplication. I want something like that > but where EH preparation can also rewrite the non-EH paths to call the > funclet, and to do that robustly I think we'd need to wed the cleanupblock > to that %finally label and wed that conditional branch to the unwind. > > > > Regarding how bad the growth can be, the problem case is > finally-inside-finally, not try-inside-try: > > > > foo() {...

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: > > > > - Do the new forms of resume have any implied read/write side-effects, or > do they work just like a branch? In particul...

...> IR generation. Do you also mean to impose this as a restriction on other > IR generators, and as a property that IR transformations must preserve? > I.e., is this something that EH preparation can assume? > EH preparation should not assume that each basic block lives in exactly one funclet. People seem to get really upset when I suggest that we change the language rules to maintain that invariant. :-) Instead, the EH preparation pass is responsible for establishing that invariant by duplicating blocks, but it should be *way* easier with real basic block terminator instructions to ma...

...of optimization is wreaking havoc for our current MSVC compatible EH implementation (hence the redesign), but I guess the Itanium ABI scheme doesn't have a problem with it. I suppose that is closely related to your concerns about inlining, I just hadn't made the connection. In theory the funclets should be able to share code blocks without any problem. The entry and exit points are the critical parts that make them funclets. I'm just not sure how we can get the optimization passes to recognize this fact while still meeting the MSVC runtime constraints. Reid's proposal of separat...

...happen? > > > > OTOH, we can easily establish the invariant at the MIR level. We should > always be able to assign each MBB a unique most recently active call site > and an SP adjustment level. We can easily teach BranchFolding to preserve > this invariant. We already do it for funclets. > > > > I’m not really concerned with funny usage of calls to alloca() in call > arguments, or anything like that. I’m happy to pick whatever rule is > easiest for us. I’m more concerned with ensuring nothing blows up if we > inline a call to a function that contains a VLA,...

``We all know'' that R has more flexible and nicer color specifications than S-plus. There are situations however, where I'd like to specify colors numerically, e.g. 1) convenience of using different colors in a for(.) loop or 2) backward compatibility with S. In S, there's the quite known ``standard'' col = 0 :<==> current background color [ = white by

...f 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 generate separate MachineFunctions for each subfunction in turn. I repeat, we can stop doing outlining in IR. This was just a mistake, because I was afraid of grappling with CodeGen. WinEHPrepar...

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

...ot the case, we'd use the __gxx_personaltity_v0-style landingpad approach and make a new personality variant that understands MS RTTI. We could try to do all this outlining in Clang, but that blocks a lot of LLVM optimizations. Any object with a destructor (std::string) is now escaped into the funclet that calls the destructor, and simple transformations (SROA) require interprocedural analysis. This affects the code on the normal code path and not just the exceptional path. While EH constructs like try / catch are fairly rare in C++, destructor cleanups are very, very common, and I'd rather...

...ory address. Software exceptions are initiated explicitly by applications or the operating system. Windows SEH (Structured exception handling) is a mechanism for handling both hardware and software exceptions. Windows C++ Exception Handling is almost fully supported in LLVM. Detailed design and new FuncletPad IR can be seen in https://llvm.org/docs/ExceptionHandling.html#exception-handling-using-the-windows-runtime<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fllvm.org%2Fdocs%2FExceptionHandling.html%23exception-handling-using-the-windows-runtime&data=02%7C01%7Ctentzen%40mi...

...llthrough, goto, break, continue, return or whatever else you like, because after that point you cannot rethrow anymore. We could try to do all this outlining in Clang, but that blocks a lot of >> LLVM optimizations. Any object with a destructor (std::string) is now >> escaped into the funclet that calls the destructor, and simple >> transformations (SROA) require interprocedural analysis. This affects the >> code on the normal code path and not just the exceptional path. While EH >> constructs like try / catch are fairly rare in C++, destructor cleanups are >> ve...

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