This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] MIPS: mips16e machine patterns - zeb/zeh seb/seh
David Ung <firstname.lastname@example.org> writes:
> I thought Ian's original comment was that if a vendor decides to
> implement MIPS32/MIPS64 with only mips16 support, we can add the option
> of -mno-mips16e then (you would have to do something like -march=mips32
> -mno-mips16e -mips16).
Ick. Please no. My answer is the same: suppose we key the choice of
MIPS16e instructions off -mips16 and -march. If someone designs the
kind of architecture you describe, they should do the same thing.
They should add a -march=* option for their architecture and key
the choice of MIPS16 instructions off that.
If people design processors whose ISAs deviate from the known -march=*
settings, they should expect to have to add their own -march setting.
> While non-MIPS32/64 cpu can choose if they want MIPS16 or MIPS16e.
> If for some unknown reason, a MIPS32/64 ISA and MIPS16 ASE is
> implemented, then -mno-mips16e need to be introduced. But then it's not
> really MIPS32/64 compliant anyway, and arguably shouldn't even be call
> that legally.
Right. And in this case, I don't like adding something that isn't
useful for known reasons, just for hypothetical (and rather
odd-sounding) future situations.
> I am not against either (a) or (b), but it seems there's now an option
> (c). Though this is a bit confusing, it is what the architecture
> specification defines.
I don't understand what you mean by the last sentence. Why aren't
(a) and (b) what the architecture specification defines?