[PATCH, MIPS] Alter default number of single-precision registers

Richard Sandiford rdsandiford@googlemail.com
Wed Apr 30 06:55:00 GMT 2014


Matthew Fortune <Matthew.Fortune@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.

You need to document the new option in the texi file.

> 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.

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.

Thanks,
Richard



More information about the Gcc-patches mailing list