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

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Thu May 24 13:00:24 PDT 2018


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>


More information about the llvm-dev mailing list