[PATCH v2] ARM: __attribute__ ((reg_return))

[Zack Weinberg]

Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
>> On Mon, Sep 10, 2007 at 02:33:30AM -0700, Zack Weinberg wrote:
>>> Here is a revised version of my patch from last week [ 
>>> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00163.html ] which adds an 
>>> ARM-specific type attribute that overrides the ABI and causes an aggregate to 
>>> be returned in registers.  Aggregates of up to 16 bytes can be returned this 
>>> way (in r0-r3).
>> FWIW, I also think it's bizarre to have this as a type attribute.  I
>> understand it made the implementation easier, but it's harder to
>> explain.  And we should be able to do this as automatically
>> as an optimization for local functions - messing around with the
>> attributes of the return type is a non-starter.

I really don't think it is possible to make it a function attribute, for 
one language reason and one QoI reason.  The language reason:  if we did 
it your way, this fragment would be acceptable code:

    struct S { int a, b; };
    struct S foo(void) __attribute__ ((reg_return));
    struct S (*ptr)(void) = foo;

But any caller of 'ptr' will be looking for the return value in the 
normal place, not where 'foo' will put it.  Therefore, that last
assignment needs to be a type error.  My way, we get that for free.  I 
don't believe we have any way of requiring that function attributes 
match in function pointer assignment.

The QoI reason: any function that returns a structure must (yes, I know 
there are exceptions) declare a local variable with the same type as the 
structure.  On ARM, local variables with a structure type larger than 
two words are normally put on the stack.  This produces suboptimal code 
when the structure is going to be returned in registers; GCC is (even in 
4.3) not able to eliminate all the memory accesses or the stack slot. 
This is why I invented the override_record_mode target hook, to force 
reg_return structures to be kept in registers.  Obviously, if we make 
the attribute be on the function, there is no way to do that.

I agree that we ought to be able to do this automatically as an 
optimization for local functions, but I don't see why "messing around 
with the attributes of the return type" would be a non-starter.  We may 
not have any way to do it now, but it seems like a thing that could be 
done, since (in the hypothetical) the variant type would not escape.

> I suppose the other alternative would just be for Zack to write the code
> in assembly (or take his patch, compile the code, and then paste in the
> assembly he gets).  If we're getting good code from C, though, that does
> seem nicer.

This was intended for 1320, and I'm probably going to do it in assembly 
in the end, because the optimizers seem to have too many holes to do it 
in C (see discussion in that issue).  However, Paul said that there had 
been other requests for this or a similar feature.

zw