Re: RFC: MIPS clones without lwl/lwr/swl/swr

[Thiemo Seufer <ths at networkno dot de>]

Richard Sandiford wrote:
> Marek Michalkiewicz <marekm@amelek.gda.pl> writes:
> > The patch below (for mainline) is an attempt to support MIPS clones
> > which don't have the patented lwl/lwr/swl/swr instructions.  This
> > would be useful mainly for the Realtek RTL8181 "Wireless LAN Access
> > Point / Gateway Controller", based on the Lexra core.  Linux/uClibc
> > port for the RTL8181 is available at http://rtl8181.sourceforge.net/ .
> >
> > This is not tested (other than it compiles), so not meant for
> > inclusion in the official GCC source just yet - but I kindly ask
> > you (especially MIPS hackers, because I'm not yet very familiar
> > with this architecture) to review it and tell me if it looks good.
> 
> Looks good to me.
> 
> The MIPS port usually guards this sort of instruction selection with an
> ISA_HAS_* macro (ISA_HAS_COND_TRAP, ISA_HAS_CLZ_CLO, etc.).  One thing
> I'd like to see is a new ISA_HAS_* macro to say whether lwl/lwr,
> etc. are available.

I don't think those should be handled as a separate ISA, for several
reasons:
- A separate ISA definition for four missing insns is very heavyweight.
- There might be CPUs which conform to different ISAs except for those
  instructions.
- The patents are IIRC running out soon-ish, which makes it less likely
  for new CPUs to come without lwl/lwr/...

> The macro would be false if your new option is
> passed and would also be false for TARGET_MIPS16.

This sounds ...wrong. MIPS16 is not an ISA, and CPUs with MIPS16 ASE
typically have lwl/lwr/... I see that some ISA_HAS_* macros test
for TARGET_MIPS16, AFAICS this will bite us if we ever start to support
mixed mode compilation (with the mode determined by profiling data).

A GENERATE_PATENTED macro seems to be a better choice.

> If at some point
> in the future, -march is extended to support a processor without the
> patented instructions, the macro would be false when generating code
> for that processor.
> 
> > Suggestions for a better name for this option are also welcome.
> 
> I've no strong opinions about that, but I don't see any need to
> shorten "patent-free" to "patfree".

-m{,no-}patent-free is ok IMHO. For convenience there should also be a
-march=rtl8181 switch which implies the patent free mode.


Thiemo