[llvm-dev] LLVM SEH docs -- enregistration of locals in nonvolatile registers?

[Jay K via llvm-dev]

Yes and more. I'm pretty sure you can use the variables in the handler, and maybe change them.


I *think*:

You can read them either from Context or more likely DispatcherContext->Context.

  I think the first is at the point of the exception and the second is having unwound to this handler, so the second.

You can write them by calling RtlVirtualUnwind until EstablisherFrame matches where you want to unwind to, and using the ContextPointers is offers.


i.e. instead of only using the EstablisherFrame.


i.e. I believe the intent of the design is that exception handling still allows pretty much all optimization you would have done w/o EH (at the cost of having to generate data, for example chained unwind for shrink wrapping, and possibly cumbersome access in the handler, etc.)..


I wish the documentation was clearer here.


I can't argue if it fits into the larger framework.


 - Jay


________________________________
From: Reid Kleckner <rnk at google.com>
Sent: Thursday, May 24, 2018 8:00 PM
To: jayk123 at hotmail.com
Cc: llvm-dev
Subject: Re: [llvm-dev] 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 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 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<mailto:llvm-dev at lists.llvm.org>> wrote:
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 them across calls like  normal in the "original" function.

I  haven't seen Visual  C++ to such enregistration (nonvolatiles across calls in functions with EH), but you can do it in assembly.

nvlocala.asm here  http://jaykrell2.blogspot.com/2017/10/windows-amd64-abi-nuances-part-1.html

I should change it to print the nonvolatiles from context to demonstrate the point.

 - Jay



_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180524/1da3a80c/attachment.html>