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] MIPS: mips16e machine patterns - zeb/zeh seb/seh


David Ung <davidu@mips.com> 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?

Richard


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