llvm dev - May 2018 - LLVM SEH docs -- enregistration of locals in nonvolatile registers?

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

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>
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
> 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/bfabc360/attachment.html>

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>