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: 64bit floating point support for MIPS32R2


Richard Sandiford wrote:
David Ung <davidu@mips.com> writes:

This patch adds -mfp64 for MIPS32R2 to allow the use of 64bit float
insn, mfhc1/mthc1 instructions to access the high half of the FPU
register.  I've restricted the -mgp32 -mfp64 to O32 only.

Is that because you don't want to specify the changes to the 32-bit EABI at this stage, or because there are known interaction problems? (Either's fine, I'm just curious.)

Mainly because its untested. I sort of remember it failed with function prologues where it tries to save floats ($f12/$f13 etc) but still treating it as 32bit. This may well be changed now. I am not sure if it will just work, should be easy to verify though.


Re-tested on cross-compiler (mipsisa32-sde-elf, O32 abi) under GNU sim
with flags "-mip32r2 -mfp64".  regressions mostly ok.  (39 failures
when running "-mips32r2", 42 failures with "-mip32r2 -mfp64")
Bootstrapped on linux.

Sorry to be a git, but I'd really rather the results were the same for both multilibs before anything goes in (or at least for there to be known reasons for the differences, if the differences aren't directly related to the new option combination).

Ok, looks like the regressions are all ok now. (my last test probably didn't do a complete rebuild).


=== gcc tests ===

Schedule of variations:
    mips-sim-sde32/-mips32r2/-mfp64

=== gcc Summary ===

# of expected passes            40247
# of unexpected failures        39
# of unexpected successes       1
# of expected failures          74
# of unresolved testcases       1
# of untested testcases         28
# of unsupported tests          413

<snip>

+(define_insn "*movdf_hardfloat_mips32r2_fp64"
+  [(set (match_operand:DF 0 "nonimmediate_operand" "=f,f,f,m,m,*f,*d,*d,*d,*m")
+	(match_operand:DF 1 "move_operand" "f,G,m,f,G,*d,*f,*d*G,*m,*d"))]
+  "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT && TARGET_FLOAT64


Missing !TARGET_64BIT here. Might as well drop TARGET_DOUBLE_FLOAT
for consistency with your other patterns; it will never be false if
TARGET_FLOAT64. As above, I think *movvdf_hardfloat_gp32_fp64
would be a better name.

hmm, that makes movdf_hardfloat_32bit needing !TARGET_64BIT aswell as !TARGET_FLOAT64.


+   && (register_operand (operands[0], DFmode)
+       || reg_or_0_operand (operands[1], DFmode))"
+  { return mips_output_move (operands[0], operands[1]); }
+  [(set_attr "type"	"fmove,xfer,fpload,fpstore,store,xfer,xfer,arith,load,store")
+   (set_attr "mode"	"DF")
+   (set_attr "length"	"4,4,*,*,*,8,8,8,*,*")])


I think the second length should be 8, because it splits into an
mtc1 and an mthc1, but correct me if I'm wrong.  Looks good otherwise.

aye. For which case that would make the above pattern redendent. Could just use movdf_hardfloat_32bit.


<snip>

The main missing thing I can see is the documentation changes
I mentioned before, including the effect that -mfp64 has on the ABI.
Otherwise, with the above fixed, and with the regressions from -mfp32
smoothed out, the patch looks good to go.

ok, I'll add something in the "Generate code for the given ABI" section.
I am not sure if would be suitable to add a note under -mfp64, but I guess it does no harm.


David.


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