llvm dev - Sep 2016 - setjmp/longjmp and volatile stores, but non-volatile loads

Reid Kleckner wrote:
> On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> 
>     model. In order to ensure that changes performed in a try/setjmp==0
>     block survive the longjmp, the changes must be done via volatile
>     operations.
> 
> If you want to observe those volatile store updates, you're really
going
> to need to volatilize the load operations. In your example, LLVM does
> not model the CFG edge from the longjmp to the setjmp. This leads LLVM
> to conclude that the only reaching definition of 'loops' at the
point of
> the load in the else block is 'loops = 0'.
Ok, thanks for confirming this approach is not going to work.
> Volatilizing all operations on local variables is going to kill your
> performance, obviously. You should really emit invoke instructions in
> your frontend. You can either use your own EH personality, or the
> existing SjLj EH personality, which will optimize on a correct CFG and
> then volatilize all values live across exceptional edges. Then the LLVM
> CFG will be correct, and you'll get pretty good code.
The main reason for using setjmp/longjmp is to maintain compatibility
between code compiled with the LLVM backend and with our existing code
generators . Switching to the SjLj personality would defeat that I think
(it seems to use LLVM-defined internal data structures for storing the
context information, such as the "five word buffer in which the calling
context is saved"). In that case it would be better to immediately
switch to ehframe-based exception handling so as to at least reap some
benefits in the process.

It is not clear to me from reading
http://llvm.org/docs/ExceptionHandling.html whether it is possible to
use our own setjmp/longjmp infrastructure without modifying LLVM. I'm
only interested in getting the LLVM CFG correct. I don't need any
runtime support, data structures (ehframe) or context information from
LLVM. All of our exception state is stored in TLS structures that can be
obtained by calling routines in our own runtime.

So, can I use invoke and landingpad without using any of the other
exception handling intrinsics? (in combination with a dummy personality
function) Or will LLVM in all cases insist on using ehframe information,
a (C++-)ABI-compliant personality function, and possibly linking in
parts of its own runtime that depend on this information being correct?

Thanks,


Jonas

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at
watlock.be>
wrote:
> Reid Kleckner wrote:
> > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev
> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> >
> >     model. In order to ensure that changes performed in a
try/setjmp==0
> >     block survive the longjmp, the changes must be done via volatile
> >     operations.
> >
> > If you want to observe those volatile store updates, you're really
going
> > to need to volatilize the load operations. In your example, LLVM does
> > not model the CFG edge from the longjmp to the setjmp. This leads LLVM
> > to conclude that the only reaching definition of 'loops' at
the point of
> > the load in the else block is 'loops = 0'.
>
> Ok, thanks for confirming this approach is not going to work.
>
> > Volatilizing all operations on local variables is going to kill your
> > performance, obviously. You should really emit invoke instructions in
> > your frontend. You can either use your own EH personality, or the
> > existing SjLj EH personality, which will optimize on a correct CFG and
> > then volatilize all values live across exceptional edges. Then the
LLVM
> > CFG will be correct, and you'll get pretty good code.
>
> The main reason for using setjmp/longjmp is to maintain compatibility
> between code compiled with the LLVM backend and with our existing code
> generators . Switching to the SjLj personality would defeat that I think
> (it seems to use LLVM-defined internal data structures for storing the
> context information, such as the "five word buffer in which the
calling
> context is saved"). In that case it would be better to immediately
> switch to ehframe-based exception handling so as to at least reap some
> benefits in the process.
>
Sounds right.

> It is not clear to me from reading
> http://llvm.org/docs/ExceptionHandling.html whether it is possible to
> use our own setjmp/longjmp infrastructure without modifying LLVM. I'm
> only interested in getting the LLVM CFG correct. I don't need any
> runtime support, data structures (ehframe) or context information from
> LLVM. All of our exception state is stored in TLS structures that can be
> obtained by calling routines in our own runtime.
>
> So, can I use invoke and landingpad without using any of the other
> exception handling intrinsics? (in combination with a dummy personality
> function) Or will LLVM in all cases insist on using ehframe information,
> a (C++-)ABI-compliant personality function, and possibly linking in
> parts of its own runtime that depend on this information being correct?
>
I would say that the coupling between LLVM generated code and the HP unwind
interface is pretty low. The only call LLVM emits is to _Unwind_Resume, so
you would have to go into llvm/lib/CodeGen/DwarfEHPrepare.cpp and teach
LLVM what you want it to call in your runtime for your EH personality.

Other than that, LLVM mostly emits ehframe unwind info and the LSDA, which
describes the landingpad PCs and how to get there. You can either try to
interoperate with that, or you'll have to change LLVM to emit your own LSDA
format. At this point we support 3-ish distinct personalities, all with
their own LSDA format, so there's a fair amount of prior art to look at in
llvm/lib/CodeGen/AsmPrinter/(anything EH related).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160930/c75fbd1e/attachment.html>

On 30/09/16 20:10, Reid Kleckner wrote:
> On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at
watlock.be
> <mailto:jonas-devlists at watlock.be>> wrote:
>
>     So, can I use invoke and landingpad without using any of the other
>     exception handling intrinsics? (in combination with a dummy personality
>     function) Or will LLVM in all cases insist on using ehframe
information,
>     a (C++-)ABI-compliant personality function, and possibly linking in
>     parts of its own runtime that depend on this information being correct?
>
>
> I would say that the coupling between LLVM generated code and the HP
> unwind interface is pretty low. The only call LLVM emits is to
> _Unwind_Resume, so you would have to go into
> llvm/lib/CodeGen/DwarfEHPrepare.cpp and teach LLVM what you want it to
> call in your runtime for your EH personality.
I thought I had finally figured out how to dance around this, but while 
I got close, it's not perfect :/

Recap: we use setjmp/longjmp for our exception handling on all platforms 
in our regular (non-LLVM) code generators. I'd like to use the same 
infrastructure with the LLVM code generator for code interoperability 
purposes (the LLVM SjLj personality is not binary-compatible with our 
existing setjump/longjump buffers).

What I did was:
1) create a dummy personality function in our run time library that 
basically always says "no, this frame does not wish to handle this 
exception nor does it have any clean-up code", and specify it as 
personality function for any function that deals with exceptions
2) create a BBL with a landingpad and no other code at the end of every 
try-block
3) in the try-blocks themselves, replace all calls with invokes that 
unwind to this landingpad BBL

Then, I tried the following:
a) if the longjmp for the try-block is taken (i.e., the setjmp right 
before the try-block returns a non-zero value), jump to the landingpad BBL.

-> Problem: LLVM does not allow regular jump edges to landingpad BBLs

b) since the landingpad is empty anyway and falls through into the next 
BBL (which contains the start of our actual exception handling code), 
jump to that next BBL from setjmp.

-> Problem: even though I do not insert code in the landingpad BBLs, 
LLVM may still add code to them, e.g. for (LLVM-created) phi-nodes.

I can't think of any solution to deal with this :/


Jonas