[llvm-commits] [llvm] r50075 - in /llvm/trunk: lib/Target/X86/README-X86-64.txt lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86MachineFunctionInfo.h test/CodeGen/X86/x86-64-sret-return.ll

Dan Gohman gohman at apple.com
Tue Apr 22 11:34:30 PDT 2008


On Apr 22, 2008, at 1:41 AM, Duncan Sands wrote:
> Hi Dan,
>
>> +A better implementation would be to relax the LLVM IR rules for sret
>> +arguments to allow a function with an sret argument to have a non- 
>> void
>> +return type, and to have the front-end to set up the sret argument  
>> value
>> +as the return value of the function. The front-end could more easily
>> +emit uses of the returned struct value to be in terms of the  
>> function's
>> +lowered return value, and it would free non-C frontends from a
>> +complication only required by a C-based ABI.
>
> there is already some support for this in llvm-gcc, i.e. having a  
> function
> return the "shadow" pointer.  In llvm-abi.h (note the bit about  
> RetPtr):
>
>  /// HandleAggregateShadowArgument - This callback is invoked if the  
> function
>  /// returns an aggregate value by using a "shadow" first parameter,  
> which is
>  /// a pointer to the aggregate, of type PtrArgTy.  If RetPtr is set  
> to true,
>  /// the pointer argument itself is returned from the function.
>  void HandleAggregateShadowArgument(const PointerType *PtrArgTy,  
> bool RetPtr){}

Ok, so the work remaining would be to actually implement
this RetPtr argument :-). Well, that and updating
StructRetPromotion and updating the various places around
LLVM that assume/require functions with sret arguments to
have a void return.

Dan




More information about the llvm-commits mailing list