similar to: LLVM SEH docs -- enregistration of locals in nonvolatile registers?

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

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

I think this is the same underlying issue as https://bugs.llvm.org/show_bug.cgi?id=40320. CCing Reid, who's had a bunch of thoughts on this in the past. On 1/11/20, 10:25 AM, "llvm-dev on behalf of Chrulski, Christopher M via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Hi, I've run into a bug with the LLVM

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 work,

typedef struct vtable_t { int (*pf4)(int a, int b, int c, int d); int (*pf5)(int a, int b, int c, int d, int e); } vtable_t; int f1(int (*pf4)(int a, int b, int c, int d)) { return pf4(1, 2, 3, 4); } int f2(vtable_t *vt) { return vt->pf4(1, 2, 3, 4); } gcc and clang will not tailcall these on arm with -O3. int f3(int (*pf5)(int a, int b, int c, int d, int e)) { return pf5(1, 2, 3,

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 information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,

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

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

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

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

On Mon, May 18, 2015 at 11:48 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-18 13:32:54 -0400, Reid Kleckner said: > >> >> Right, doing our own personality function is possible, but still has half >> the challenge of using __CxxFrameHandler3, and introduces a new runtime >> dependency that isn't there currently. Given that it won't save

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

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

Sorry that also suffered from signature mismatch. So how about more like: typedef struct vtable_t { int (*pf4)(int a, int b, int c, int d); int (*pf5)(int a, int b, int c, int d, int e); } vtable_t; int f3(int (*pf5)(int a, int b, int c, int d, int e), int a, int b, int c, int d) { return pf5(a, b, c, d, d + d); } int f4(vtable_t *vt, int a, int b, int c, int d) { return vt->pf5(a, b,

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

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

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

I'm having trouble changing the machine name programmatically on Samba 4 (running under systemd). There's no "netbios name" option in smb.conf, so I'm relying on it using the hostname. Here's what I'm doing: 1) Call sethostname() with the new name. 2) Write the same name into /etc/hostname, to make it nonvolatile. 3) Read a decimal number from /var/run/smbd.pid.

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