search for: funclets

...reate these do not take operand bundles) Therefore, PGO would need to determine the appropriate funclet value with colorEHFunlets to identify the funclet operand bundle to attach to the instrumentation calls. Unfortunately, because it is possible that a basic block could be associated with multiple funclets or both a funclet and outside the funclet, this may also need to clone some of basic blocks similar to the WinEHPrepare.cpp routine cloneCommonBlocks(), prior to computing the instrumentation. Pros: does not disable value profiling opportunities. Cons: complex to implement due...

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

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

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

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

...l, I don't think it's helpful to try to explain this in the documentation. The document is intended to aid LLVM developers who don't particularly care about WinEH but want to understand it enough to avoid breaking it. If we wanted to exploit this optimization opportunity, we would clip funclets out of the CFG and add edges from invokes to all possible catchret destinations. Then the CSR mask of the call would naturally provide the right register allocation barrier. On Thu, May 24, 2018 at 8:13 AM Jay K via llvm-dev <llvm-dev at lists.llvm.org> wrote: > https://llvm.org/docs/Exc...

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

...path) > each of expr2 through exprn. The next funclet will include each of expr3 > through exprn. Etc. > > > > Another problem I'd have relying on early inlining is that when the CLR > asks the LLILC Jit to jit one method, it expects the result to be one > method (plus funclets), not n methods… > > > > Thanks > > -Joseph > > > > > > *From:* Reid Kleckner [mailto:rnk at google.com] > *Sent:* Tuesday, May 19, 2015 7:26 PM > > *To:* Joseph Tremoulet > *Cc:* LLVM Developers Mailing List; Bill Wendling; Nick Lewycky; Kaylor, >...

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

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

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

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

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

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

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

...r can see its control flows. In #2 case of above example, the control flowing from normal execution inner _finlly, passing through outer _finally, and landing in $t10 cannot be represented by LLVM IR today. Similarly in #4, the control starting from RtlRaiseException() passing through both _finally funclets then landing in $t10 was not seen. To precisely represent _local_unwind flow, our proposed solution is: * Add one more catchpad/catchret pair that forwards control to local_unwind target. I.e., this extra Catchpad is the reentrance point for the _local_unwind() runtime. * This catchpa...

...the exceptional path. While EH >> constructs like try / catch are fairly rare in C++, destructor cleanups are >> very, very common, and I'd rather not pessimize so much code. >> > > Right, but __CxxFrameHandler3 already forces you to outline destructor > cleanups into funclets. So if you wanted to stop doing that you have to > write your own personality function right? > No, I believe if we want to be able ABI compatible, we need to outline at least destructor cleanups, regardless of what personality we use. > What I am saying is, if you can design the person...

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