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

[Paul Brook <paul at codesourcery dot com>]

> >> 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.

This can't be a new problem. x86 has at least 2 function attributes that 
effect the ABI (stdcall and regparm).

> 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.

Yuck. This suggests that the attribute is somewhat mis-named. It effects code 
generation as well as the ABI. On a related note, we need documentation for 
the new attribute.

Paul