Re: mips16 and nomips16

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Fri, 18 Jan 2013, Richard Sandiford wrote:
>
>> > I would assume that foo would be nomips16 and goo would be mips16.
>> >
>> > The definition of plain foo() or goo() says that nothing is specified.
>> >
>> > What is not clear then?
>> >
>> > This is how all such other attributes in gcc are handled.
>> 
>> Well, in a way, these are the only such attributes in GCC :-)
>> I don't think any other port supports switching between different
>> ISA modes like this.
>> 
>> I think the original authors really wanted "mips16" and "nomips16" to be
>> type attributes rather than decl attributes.  nomips16 function pointers
>> and mips16 function pointers would be mutually-incompatible subtypes of
>> unannotated function pointers, so you would be able to implicitly
>> convert an annotated function pointer to an unannotated one, but not the
>> other way, and not between annotated function pointers.  GCC didn't at
>> the time (and as far as I know still doesn't) have hooks to enforce that
>> though.  The attributes therefore ended up being implemented as strict
>> decl attributes in the hope that they could be made type attributes in
>> future without breaking backwards compatibility.
>> 
>> Not having those hooks means that the validity and semantics of:
>> 
>>  void foo();
>>  void __attribute((subtype)) foo();
>> 
>> aren't really defined.  Does foo() keep its original type or change to
>> the subtype?  It's also not defined whether:
>> 
>>  void __attribute((subtype)) foo();
>>  void foo();
>> 
>> is invalid, or whether the subtype from the first declaration carries
>> over to the second.  Etc.  (To be clear, I'm not trying to start a
>> discussion on the right semantics, or anything like that.  I'm just
>> saying that I don't think the semantics are defined yet, although
>> I could be wrong.)
>
>  FWIW, I think the benefit from these attributes being a type property is 
> questionable to say the least.  My understanding is the only application 
> is to prevent the tail-call optimisation from being applied to non-PIC 
> standard MIPS functions that otherwise would have to make a direct jump to 
> MIPS16 code for which there is no hardware support (note that there is no 
> issue with PIC code as with register jumps the ISA bit can be freely set 
> at will as required).

I think the main benefit was more to avoid unnecessary hard-float
interworking cruft.  If you're calling an indirect function (including
vtable function) whose type has a mips16 attribute, you know that
float values will be returned in GPRs without going through the
libgcc stub.  So...

>  If that is the case, then perhaps producing a suitable call thunk 
> instead, similar to these we use to pass floating-point arguments around 
> with MIPS16 functions or to call PIC code from non-PIC code statically 
> linked together, so that all standard MIPS code is link-time compatible 
> with MIPS16 would be a better option?

...I think the idea was to avoid this kind of overhead.

But like I say, I might be misrepresenting things, and I'm certainly open
to removing the check if there's agreement we don't want type attributes.

FWIW, there's also the "target" attribute, which is designed specifically
for turning options on and off at the function definition site, and which
also has an associated pragma for controlling a block of functions.
That isn't implemented yet for MIPS, but should be.  E.g. we could have
target("mips16"), target("no-mips16"), target("micromips") and
target("no-micromips").

So one alternative might be to keep the current attributes as they are
and implement "target".

Richard