[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