[llvm-commits] [llvm] r71610 - in /llvm/trunk: include/llvm/CodeGen/MachineFunction.h include/llvm/Intrinsics.td lib/CodeGen/MachineFunction.cpp lib/CodeGen/PrologEpilogInserter.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp lib/Target/ARM/AR

[Eli Friedman]

On Thu, May 14, 2009 at 10:41 AM, Jim Grosbach <grosbach at apple.com> wrote:
>> How exactly will the second argument to builtinlongjmp be used?  gcc
>> requires that the second argument to __builtin_longjmp is a constant
>> 1.
>
> There's some funkiness there. GCC uses flow control tricks with passing the
> address of a label to tell the builtin_setjmp call site that control came
> from a builtin_longjmp rather than straightline execution. LLVM doesn't
> allow the addresses of basic blocks to escape the containing function
> directly, so that solution doesn't fit too well.

It shouldn't be impossible, just slightly tricky.  The restriction on
taking the address of a basic block doesn't apply to machine basic
blocks; an obvious example is jump tables.

> Instead, I'm using an
> explicit value passed back from the builtin_longjmp. This interoperates
> properly with the GCC builtin_setjmp since what our exception handling is
> looking for is zero or non-zero, not specific values. Since the LLVM version
> needs to guarantee a non-zero value, I didn't see a reason to restrict it to
> an explicit literal '1'.

I'm reasonably sure that the gcc implementation doesn't intend to
guarantee the state of any register other than the stack pointer
register and the frame pointer register.  We don't want to run into
the situation where a new version of gcc accidentally breaks
compatibility.

-Eli