https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123381
--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #4)
> What helps is slightly disparaging ('?') the reg-reg alternative but I don't
> like that (I don't like any of these cost-altering switches). Another
> option would be '^' that disparages slightly if the operand requires a
> reload. That seems more appropriate and imitates what the cycle-danger
> check would do if we didn't have the scratch.
>
> Still very much feels like a hack, though.
I don't think we can reply on '?' or '^' as solid fixes, since they don't stop
us from going down the path we're trying to discourage, it only makes it harder
to hit that ICE.
I'll note I did try adding a secondary memory needed hunk below which fixes the
ICE, but I wasn't 100% happy with the code being generated. I found it
interesting to compile the test case with one fewer formal argument so that 'x'
is passed in a register rather than on the stack and then watch reload
successfully reload that. I didn't get a chance to track down what it was
doing that we're missing though yet.
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 949616a63d3..36805cc367b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -10642,6 +10642,9 @@ riscv_secondary_memory_needed (machine_mode mode,
reg_class_t class1,
{
bool class1_is_fpr = class1 == FP_REGS || class1 == RVC_FP_REGS;
bool class2_is_fpr = class2 == FP_REGS || class2 == RVC_FP_REGS;
+ if (riscv_vector_mode_p (mode))
+ return class1 == V_REGS && class2 == GR_REGS
+ || class1 == GR_REGS && class2 == V_REGS;
return (!riscv_vector_mode_p (mode)
&& GET_MODE_SIZE (mode).to_constant () > UNITS_PER_WORD
&& (class1_is_fpr != class2_is_fpr)
