Another MSA related fix; this time relating to using -mno-odd-spreg.
This fixes a build-failure with gcc.c-torture/execute/20050604-1.c
when using -mabi=32 -mmsa -mno-odd-spreg.
The fix is to copy the whole vector from the odd-numbered source
register to the even numbered single-precision destination register
and then re-interpret the vector as single precision in the
destination. The mov.s is always eliminated as it is a trivial
no-op; this is permitted by the architecture as the single-precision
and double-precision registers overlay with the 0th element of the
MSA registers. Also, trivial no-ops were already being generated
and eliminated prior to this change when source and destination
register numbers happened to be the same.
No additional test failures introduced when running the testsuite
with -mmsa. The fix is covered by a pre-existing test so no new
testcase added.
gcc/
* config/mips/mips-msa.md (msa_vec_extract_<msafmt_f>): Update
extraction from odd-numbered MSA register
Committed.
Thanks,
Matthew
diff --git a/gcc/config/mips/mips-msa.md b/gcc/config/mips/mips-msa.md
index accb8de..c80be47 100644
--- a/gcc/config/mips/mips-msa.md
+++ b/gcc/config/mips/mips-msa.md
@@ -366,7 +366,20 @@ (define_insn_and_split "msa_vec_extract_<msafmt_f>"
"#"
"&& reload_completed"
[(set (match_dup 0) (match_dup 1))]
- "operands[1] = gen_rtx_REG (<UNITMODE>mode, REGNO (operands[1]));"
+{
+ /* An MSA register cannot be reinterpreted as a single precision
+ register when using -mno-odd-spreg and the MSA register is
+ an odd number. */
+ if (<UNITMODE>mode == SFmode && !TARGET_ODD_SPREG
+ && (REGNO (operands[1]) & 1))
+ {
+ emit_move_insn (gen_rtx_REG (<MODE>mode, REGNO (operands[0])),
+ operands[1]);
+ operands[1] = operands[0];
+ }
+ else
+ operands[1] = gen_rtx_REG (<UNITMODE>mode, REGNO (operands[1]));
+}
[(set_attr "move_type" "fmove")
(set_attr "mode" "<UNITMODE>")])
