https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-02-07
Ever confirmed|0 |1
--- Comment #9 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #8)
> Hm, if GCC won't accept clobbering a hardreg that overlaps the output
> hardregs holding the return value (operands[0]), then it's less obvious.
Yes, I was afraid of that. (See below).
I've also tried using LRA without the patch, but the problem persists.
> r0
> is always suitable then and does not require mentioning in the RTL template,
That might be true, but that could be a source of future silent wrong-code
bugs.
> but constrains scheduling as Rich said.
I'm not sure whether this will have any effects on scheduling. Maybe just some
few cases where r0 could be used to calculate something else, or access memory
via index-register address mode.
Anyway, I've tried the following 2-liner:
Index: gcc/config/sh/sh.md
===================================================================
--- gcc/config/sh/sh.md (revision 233200)
+++ gcc/config/sh/sh.md (working copy)
@@ -10481,7 +10481,7 @@
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
(match_operand 2 "" "")))
(use (reg:SI FPSCR_MODES_REG))
- (clobber (match_scratch:SI 3 "=&k"))
+ (clobber (reg:SI R1_REG))
(return)]
"TARGET_SH2 && !TARGET_FDPIC"
"#"
@@ -10491,6 +10491,8 @@
rtx lab = PATTERN (gen_call_site ());
rtx call_insn;
+ operands[3] = gen_rtx_REG (SImode, R1_REG);
+
sh_expand_sym_label2reg (operands[3], operands[1], lab, true);
call_insn = emit_call_insn (gen_sibcall_valuei_pcrel (operands[0],
operands[3],
... and it gets the job done for the test case in comment #1.
The patch could be a quick fix for the problem (with some comments added),
although clearly it's just wallpapering. It will also break if hard-regs are
reserved via compiler options, but luckily that's not a common use case.
When compiling the test case without -fPIC the "sibcall_valuei" pattern is used
and doesn't show any problems. So I guess the pcrel patterns like
"sibcall_value_pcrel" should be changed to get register allocation working as
for non-pcrel calls and do the pcrel stuff in a different way. But I guess
this will be some bigger rework patch.
