[llvm-commits] sret-demotion for large struct returns working on x86!

[Kenneth Uildriks]

On Mon, Nov 9, 2009 at 2:42 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote:
> On Mon, Nov 9, 2009 at 2:37 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>> If a struct can't be returned in registers, have SelectionDAGBuild
>> insert a hidden sret parameter and have return instructions store the
>> return value through the hidden pointer.  Formal arguments, return
>> instructions, and calls are all updated as needed.
>>
>> Only x86 has the code to actually check whether sret-demotion is
>> needed.... other platforms invariably report that they can return
>> values in registers, even when they can't.
>
> There is definitely an ABI issue here. For ARM AAPCS-VFP, we need to
> decide that a aggregate is to be passed in registers based on
> information like unions which aren't represented in the LLVM IR.
>
> Perhaps I've missed the overall goal. If the CC is "fast" then this
> sort of thing makes a lot of sense, but "C" and other CCs need to be
> established by the front-end and not perturbed by the backend.
>
> deep
>

The trouble is that the front-end doesn't have enough information.
You need to get all the way to the SelectionDAG before you can even
begin to determine whether the target/calling convention combo is
capable of returning your struct in registers... and if it isn't,
SelectionDAG falls over and dies when it hits the function.  So you
can't guarantee while building your IR that SelectionDAG won't abort
(unless you hardcode target-specific rules into your front-end).

This transformation will only kick in in cases where the present
version falls over and dies.  Existing, working code will behave no
differently.  Existing target-specific front-ends will not be
affected.