Re: mips16 and nomips16

[Richard Sandiford <rdsandiford at googlemail dot com>]

Sorry for the slow reply, only just saw this.

reed kotler <rkotler@mips.com> writes:
> On 01/14/2013 04:50 PM, David Daney wrote:
>> On 01/14/2013 04:32 PM, reed kotler wrote:
>>> I'm not understanding why mips16 and nomips16 are not simple inheritable
>>> attributes.
>>
>> The mips16ness of a function must be known by the caller so that the 
>> appropriate version of the JAL/JALX instruction can be emitted
>>
>>
>>>
>>> i..e you should be able to say:
>>>
>>> void foo();
>>> void __attribute((nomips16)) foo();
>>>
>>>
>>> or
>>>
>>> void goo();
>>
>> Any call here would assume nomips16
>>
>>> void __attribute((mips16)) goo();
>>
>> A call here would assume mips16.
>>
>> Which is it?  If you allow it to change, one case will always be 
>> incorrect.
>>
>> Or perhaps I misunderstand the question.
>>
>> David Daney
>>
> 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, the original implementation came from MTI, but it was a while ago
and I no longer have a record of the discussion.  (It was discussed and
submitted under a CodeSourcery contract.)  I might be misrepresenting things.

If you (MTI) are sure that we don't want them to be type attributes,
and that we should treat them more like optimisation switches, then we
can probably remove the check.  I think it's a one-way street though.

Richard