Richard Sandiford <rdsandif...@googlemail.com> writes:
> Matthew Fortune <matthew.fort...@imgtec.com> writes:
> > Hi Richard,
> >
> > When MIPSr1 introduced the ability to use odd-numbered
> > single-precision registers some implementations continued to only
> > support even-numbered single-precision registers. Notably,
> loongson3a
> > in FR=0 mode only permits the even-numbered registers to be used.
> For
> > this reason and also to coincide with other FP ABI related changes we
> > are reducing the number of single precision floating-point registers
> > available for generic architectures: MIPS32, MIPS32r2, MIPS64,
> MIP64r1
> > when using -mfp32.
> >
> > Targeting or tuning for a specific MIPS implementation which is known
> > to have odd-numbered single-precision registers usable will continue
> > to make use of all 32 registers. The -modd-spreg option has no effect
> > on the availability of odd-numbered single precision registers for -
> mfp64.
> >
> > This patch also implements REGISTER_PREFIX to simplify the use of
> > command line options like -ffixed-reg which take a register name as
> an
> > argument and the $ (dollar) in MIPS register names makes this more
> > awkward than necessary.
> >
> > Suggestions for better option names are welcome, also better
> > approaches to the tests are welcome. I'm simply relying on an ICE
> when
> > no registers are available to check the implementation.
>
> One way would be something like:
>
> void
> foo (void)
> {
> register float foo asm ("$f1");
> asm volatile ("" : "=f" (foo));
> }
>
> which gives:
>
> error: register specified for ‘foo’ isn’t suitable for data type
>
> when odd FP regs are disallowed.
Yes that's blatantly obvious :-). I took these tests from my work on
the FPXX ABI which I can't find a way to test using inline asm and
constraints. (patch due soon).
> You need to document the new option in the texi file.
Will do.
> > diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index
> > 45256e9..b012dfd 100644
> > --- a/gcc/config/mips/mips.c
> > +++ b/gcc/config/mips/mips.c
> > @@ -17120,6 +17120,21 @@ mips_option_override (void)
> > warning (0, "the %qs architecture does not support madd or msub"
> > " instructions", mips_arch_info->name);
> >
> > + /* If neither -modd-spreg nor -mno-odd-spreg was given on the
> command
> > + line, set MASK_ODD_SPREG bsaed on the target architecture, ABI
> and
> > + tuning flags. */
> > + if ((target_flags_explicit & MASK_ODD_SPREG) == 0)
> > + {
> > + if (ISA_HAS_ODD_SPREG
> > + && ((mips_tune_info->tune_flags & PTF_AVOID_ODD_SPREG) == 0))
> > + target_flags |= MASK_ODD_SPREG;
> > + else
> > + target_flags &= ~MASK_ODD_SPREG;
> > + }
> > + else if (TARGET_ODD_SPREG && !ISA_HAS_ODD_SPREG)
> > + warning (0, "the %qs architecture does not support odd single-
> precision"
> > + " registers", mips_arch_info->name);
>
> I think this should be an -march decision rather than an -mtune
> decision.
> The two existing PTF_s (which were supposed to be "processor tuning
> flags") really are -mtune decisions, since the question isn't whether
> the features are available (that's given accurately by ISA_HAS_*) but
> whether it's a good idea to use them.
>
> ISA_HAS_ODD_SPREG should probably be false for loongson
> !TARGET_FLOAT64.
> Then the decision here is whether mips_arch_info is the generic ISA or
> not.
> We could add a new flag for that (and rename "tune_flags" to simply
> "flags"
> and update the commentary) but strncmp (mips_arch_info->name, "mips",
> 4) should work too.
If we make ISA_HAS_ODD_SPREG return false for:
loongson3a && !TARGET_FLOAT64
Then the tuning option starts to make sense again as the generic mips
architectures do support the odd numbered registers but for
compatibility reasons they should be avoided.
> As you can tell, this whole what-ISA-has-what area is very old and
> needs a rework. It predates the current option machinery (and
> certainly the use of the option machinery in the driver) by many
> years...
> > @@ -1268,6 +1282,12 @@ struct mips_cpu_info {
> > /* By default, turn on GDB extensions. */ #define
> > DEFAULT_GDB_EXTENSIONS 1
> >
> > +/* Registers may have a prefix which can be ignored when matching
> > + user asm and register definitions. */ #ifndef REGISTER_PREFIX
> > +#define REGISTER_PREFIX "$"
> > +#endif
> > +
> > /* Local compiler-generated symbols must have a prefix that the
> assembler
> > understands. By default, this is $, although some targets
> (e.g.,
> > NetBSD-ELF) need to override this. */
>
> This is OK to commit as an independent patch, thanks.
OK. We are waiting for our updated copyright assignment papers to be
completed but will prepare this separately. We are going to end up
with a few patches queued on assignment.
Regards,
Matthew
