[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 14, 2009, at 11:19 AM, Eli Friedman wrote:

> 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.

That would require moving more of the control flow logic out of the  
front end, which I'm trying to avoid as much as possible. As-is,  
there's no explicit strange flow-control that needs to be represented,  
just a requirement that the target definition of the intrinsic mark  
the relevant registers as defined. The rest is "magic" as far as the  
front end is concerned.

If there's a way to represent the dispatch label aspects of the way  
GCC does this in LLVM IR, I'd love to know about it. I couldn't find  
anything.

>> 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.

I agree that's a bit ugly. Very little of any of this is really  
guaranteed by GCC, though. The libgcc stuff is pretty tightly couple  
to the compiler version already. The line between guaranteed and the- 
way-it-happens-to-work-right-now is blurry. I tried to give the back- 
end target the flexibility it needs to deal with those sorts of  
platform changes by leaving how the value is passed back up to the  
target, which can adjust as necessary. It's definitely not perfect,  
but I think it's a reasonable compromise.

-Jim