This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Mark Mitchell writes:
>It might also be reasonable to have it as a function attribute, but
>I don't think that would obviate the utility as a type attribute; if
>this is a type that you *always* want returned that way, then a type
>attribute is most convenient.

I would expect that you would want most aggregates that are 16 bytes or
less to be always returned this way.  On the other hand, you problaby
also don't want to every function that returns a small aggregate to
break the ABI.  The real utility of this attribute would be to identify
the functions can safely break the ABI, not which aggregate types can
break the ABI.

Remember, according to Zack Weinberg, the primary purpose of the attribute
is for use in the implementation of __aeabi_*divmod functions, it wasn't
for use everything that returned [ul]ldiv_t structures.  Accordingly,
he first attempted to implement it as a function attribute.  That was
a mistake because it actually needs to be an attribute of the *function
type* so that it works with indirect function calls.  Making it a type
attribute just solves that problem through the back door by adding
the attribute to the function type through one of its component types.
It would make more sense, and more consistent with it's intended use,
for it to be an attribute of the function type.

Now while I don't think you can justify it based on what users want
or expect, apparently there is still a valid reason for making it an
attribute of the type.  It solves an optimization problem he had with
the use of the type as a return value.  Maybe it's an acceptable hack,
but I have to wonder if there isn't a better solution.  Do other backends
that can return small aggregates in registers have this problem?  If so,
shouldn't it be fixed for all of them?

					Ross Ridge


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]