[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/ARMISelLowering.cpp lib/Target/ARM/ARMISelLowering.h lib/Target/ARM/ARMInstrInfo.cpp lib/Target/ARM/ARMInstrInfo.td

Jim Grosbach grosbach at apple.com
Wed May 13 11:33:10 PDT 2009

On May 13, 2009, at 11:21 AM, Chris Lattner wrote:

> On May 13, 2009, at 11:09 AM, Jim Grosbach wrote:
>>> How about llvm.save.register.state() and  
>>> llvm.restore.register.state().  LangRef should document that these  
>>> are compatible with the GCC builtins.  Also, you should use  
>>> GCCBuiltin<> in the .td file so that these work with the CBE etc.   
>>> Please make sure to update 'HasBuiltinSetjmp' and the accessors  
>>> when you rename the intrinsic.
>> I didn't put in the GCCBuiltin<> reference because these intrinsics  
>> are not exactly equivalent. The intent is to generate code that  
>> will interoperate correctly with the GCC versions, but there are  
>> differences in the implementation currently. I may be able to  
>> reconcile the details, and if so, I'll add in the GCCBuiltin bits.
> Ok.
>>>> +++ llvm/trunk/lib/CodeGen/PrologEpilogInserter.cpp Tue May 12  
>>>> 18:59:14 2009
>>>> @@ -180,7 +180,7 @@
>>>> std::vector<CalleeSavedInfo> CSI;
>>>> for (unsigned i = 0; CSRegs[i]; ++i) {
>>>>  unsigned Reg = CSRegs[i];
>>>> -    if (Fn.getRegInfo().isPhysRegUsed(Reg)) {
>>>> +    if (Fn.getRegInfo().isPhysRegUsed(Reg) ||  
>>>> Fn.doesHaveBuiltinSetjmp()) {
>>> This is unfortunate, why does PEI need to know about this?   
>>> Shouldn't the 'Int_builtin_setjmp' use and def all these registers?
>> It's the PEI that does the actual save/restore of the registers.  
>> The intrinsic just tells the function that it's necessary. This  
>> allows the actual jump buffer for the intrinsics to be very small  
>> (five words) since the majority of the context save is on the  
>> stack, not in the jump buffer.
> Ok, that makes sense.  I'm not arguing about the generated code, I'd  
> just like to get rid of the doesHaveBuiltinSetjmp() bool and special  
> case in PEI.
>> Callee-saved register values be preserved across function calls,  
>> and inside our function, any values which are live at the time need  
>> to be preserved across the setjmp() call itself. For the former,  
>> the compiler already handles the requisite dirty work in the  
>> epilogue and prologue code generation for any callee saved  
>> registers potentially clobbered by the function. When a function  
>> contains a builtin setjmp, we mark the function and consider all  
>> callee-saved registers to be used in prologue/epiloge generation.  
>> For the latter, we want to ensure that all values we care about are  
>> not stored in registers across the setjmp, so the target  
>> implementation of the intrinsic should mark it as defining all  
>> relevant registers (via Defs = ...).
> Ok, I understand how this works with your patch, but I still don't  
> understand why it is needed.  Doesn't the machine instr that you  
> insert end up using or def'ing these registers?  If so, isn't that  
> already sufficient to get PEI to do the right thing without the bool?

Ah, gotcha. I understand better what you're asking now. Sorry for the  

Hmmm... I didn't see that happening when I was working through those  
bits before; however, I may not have had everything hooked up right  
yet at the time. I agree it would be far, far preferable to not need  
the "magic save everything" flag on the function. I'll play around  
with this some more and see what I can do.

Thanks again.


>>>> +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.
> Ok.
> -Chris

More information about the llvm-commits mailing list