Re: [Patch] MIPS: mips16e machine patterns - zeb/zeh seb/seh

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

David Ung <davidu@mips.com> writes:
> On Fri, 2005-06-10 at 14:09 +0100, Richard Sandiford wrote:
>> David Ung <davidu@mips.com> writes:
>> > Looks like we've agreed to leave in the -mips16e option then.
>> > here is a revised patch.  I've added a few lines in the manual and now
>> > use GENERATE_MIPS16E instead, since TARGET_MIPS16E is already generated
>> > by mips.opt.
>> 
>> I'm a bit confused here.  I thought the two options under discussion were:
>> 
>>   (a) -mips16e as a separate flag.  You get MIPS16e instructions
>>       if and only if you use -mips16e.
>> 
>>   (b) -mips16 is always used to enable MIPS16(e) instructions.
>>       The -march setting decides whether MIPS16e is available.
>> 
>> (a) was what your first patch did and (b) was what I mentioned in
>> the review (purely for discussion purposes ;).
>> 
>> Like you say, the balance of opinion was that having a separate
>> flag was better than (b), but you now seem to have gone for a
>> hybrid in which -mips16 sometimes selects MIPS16 and sometimes
>> selects MIPS16e.  Why did you do that rather than stick with
>> your original?
>
> That's because to be MIPS32/32R2/64/64R2 ASE compliant, the full MIPS16e
> set is required, not a subset (MIPS16). I've simply made that if the
> user gave -mips16 option for mips_isa>=32, they really mean -mips16e.
> As in Ian's previous reply, -march=mips32 -mips16 will imply -mips16e.

Yeah, I don't like this though.  If there's a separate flag for MIPS16e,
that's what the user should use to get MIPS16e.  I was happy with either
(a) or (b), but this third option just seems too complicated to me.

So which is more important to you?  That -mips16 -mips32 => MIPS16e?
Or that MIPS16e be selectable by a separate command-line option?

If the first, then I don't think there's a strong argument for keeping
the separate -mips16e flag.  Ian mentioned the possiblity that another
manufacturer might produce a processor that isn't a true MIPS32 or MIPS64
implementation but that nevertheless provides full MIPS16e compatibility.
If that happens, we can just make that processor's -march flag select
MIPS16e, in the same way that you're doing for MIPS32 and MIPS64.

Or, from a slightly different angle:

At the moment, the compiler only understands the traditional MIPS16 ISA,
and you can get traditional MIPS16 code from "mipsisa32-elf-gcc -mips16",
just like you can get true MIPS III code from "mipsisa32-elf-gcc -mips3".
This may be what some users expect -mips16 to do.  IMO, the real argument
in favour of having -mips16e was that it preserved the concept of -mips16*
being an independent ISA option.

That's why I was happy with (a).  It doesn't change the meaning of -mips16
at all.  But I can also see why changing the meaning of -mips16 could make
sense, which was why I was also happy with (b).

The problem with your third option is that, once you change the meaning
of -mips16, the new -mips16e flag has no value for known processors.
It just complicates the command-line interface.

The -mips16* flags should either be independent ISA flags (as with (a))
or mode selectors (as with (b)).  I don't think they should be a mish-mash
of both.

Richard