[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

[Jim Grosbach]

On May 13, 2009, at 1:12 PM, Eli Friedman wrote:

> On Wed, May 13, 2009 at 11:09 AM, Jim Grosbach <grosbach at apple.com>  
> wrote:
>>>> +let Properties = [IntrNoMem] in {
>>>> +def int_builtinsetjmp  : Intrinsic<[llvm_i32_ty],  [llvm_ptr_ty]>;
>>>> +def int_builtinlongjmp : Intrinsic<[llvm_void_ty], [llvm_ptr_ty,
>>>> llvm_i32_ty]>;
>>>
>>> If there is no reason to have both arguments, please drop the extra
>>> one.
>>>
>>
>> I'm not sure I follow. builtinsetjmp takes a single argument, and
>> builtinlongjmp takes two. All arguments will be used.
>
> 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. 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'.

>
>
> -Eli
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits