Matthew Fortune <matthew.fort...@imgtec.com> writes:
> 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.
-march is "which instructions can I use?" and -mtune is "which instructions
give good performance?". My understanding is that you wanted to disable
the instructions for mips32r2 etc. so that they can be safely linked
with loongson3a code, in which case it's an -march rather than an
-mtune decision.
Admittedly the branch-likely case is a bit of a grey area. It can be
justified on tuning grounds because it's unlikely that deprecated
instructions will perform will in general, and the tuning for mips*
archs is supposed to be an all-round compromise. But disabling half
the FPRs for single floats can't be justified on tuning grounds.
That's never going to help performance. :-)
Thanks,
Richard
