[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #28 from Oleg Endo --- Fixed on trunk, GCC 5 and GCC 4.9. As for some of the improvements mentioned above, I've created a new PR 69803.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #27 from Oleg Endo --- Author: olegendo Date: Sat Feb 13 08:48:50 2016 New Revision: 233402 URL: https://gcc.gnu.org/viewcvs?rev=233402&root=gcc&view=rev Log: gcc/ Backport from mainline 2016-02-13 Oleg Endo PR target/67260 * config/sh/sh.md (sibcall_value_pcrel): Replace =&k scratch reg with fixed R1_REG scratch reg. gcc/testsuite/ Backport from mainline 2016-02-13 Oleg Endo PR target/67260 * gcc.target/sh/torture/pr67260.c: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/torture/pr67260.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sh.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #26 from Oleg Endo --- Author: olegendo Date: Sat Feb 13 08:46:49 2016 New Revision: 233401 URL: https://gcc.gnu.org/viewcvs?rev=233401&root=gcc&view=rev Log: gcc/ Backport from mainline 2016-02-13 Oleg Endo PR target/67260 * config/sh/sh.md (sibcall_value_pcrel): Replace =&k scratch reg with fixed R1_REG scratch reg. gcc/testsuite/ Backport from mainline 2016-02-13 Oleg Endo PR target/67260 * gcc.target/sh/torture/pr67260.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/sh/torture/pr67260.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sh/sh.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #25 from Oleg Endo --- Author: olegendo Date: Sat Feb 13 08:43:15 2016 New Revision: 233400 URL: https://gcc.gnu.org/viewcvs?rev=233400&root=gcc&view=rev Log: gcc/testsuite/ PR target/67260 * gcc.target/sh/torture/pr67260.c: Adjust additional options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/torture/pr67260.c
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #24 from Oleg Endo --- (In reply to Rich Felker from comment #18) > I thought I fixed at least one occurrence of this when I forward-ported the > FDPIC patch, but in any case, if it changed since that patch was first > written then there's almost surely a log entry and hopefully a bz explaining > the change to &k which might shed some light on the history of this code and > why it's done the way it is. The FDPIC patch you used as the starting point was obviously written at a time when the "sibcall_value_pcrel" pattern had the "=k" scratch/clobber. The GCC 4.9 branch still has this code. On GCC 5 it was fixed to "=&k" to fix wrong-code errors, but wasn't backported. Anyway, I'm going to backport r233399 to GCC 5 and GCC 4.9 which will replace it with the fixed R1_REG scratch/clobber
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #23 from Oleg Endo --- Author: olegendo Date: Sat Feb 13 08:03:44 2016 New Revision: 233399 URL: https://gcc.gnu.org/viewcvs?rev=233399&root=gcc&view=rev Log: gcc/ PR target/67260 * config/sh/sh.md (sibcall_value_pcrel): Replace =&k scratch reg with fixed R1_REG scratch reg. (sibcall_value_pcrel_fdpic): Likewise. gcc/testsuite/ PR target/67260 * gcc.target/sh/torture/pr67260.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/torture/pr67260.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #22 from Oleg Endo --- (In reply to Oleg Endo from comment #21) > > It seems the patch is not good. I see new failures when testing on sh-elf. > I will try to see what's going on there. False alarm. Those were other unrelated changes on trunk.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #21 from Oleg Endo --- (In reply to Oleg Endo from comment #17) > > > I guess because the recently added "sibcall_value_pcrel_fdpic" pattern also > uses "=k" as the clobber constraint, it might run into the same problem. To > play safe for now, I'd like to commit the following to trunk and backport it > to 5 and possibly 4.9: > > [...] It seems the patch is not good. I see new failures when testing on sh-elf. I will try to see what's going on there.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #20 from Rich Felker --- The (second) patch in comment 17 seems to have fixed the build failure for musl's complex math functions where I first encountered the problem.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #19 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #17) > Kaz, what do you think? LGTM and looks like we have no choice for 5/4.9.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #18 from Rich Felker --- I thought I fixed at least one occurrence of this when I forward-ported the FDPIC patch, but in any case, if it changed since that patch was first written then there's almost surely a log entry and hopefully a bz explaining the change to &k which might shed some light on the history of this code and why it's done the way it is.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #17 from Oleg Endo ---
I have tried this:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 233324)
+++ 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 (match_scratch:SI 3 "=k"))
(return)]
"TARGET_SH2 && !TARGET_FDPIC"
"#"
... and compiling the example in comment #1 with -m2 -mb -O2 -mlra works fine.
However, it results in the following wrong code:
mov.l .L2,r7 <<< r7 is used by function arg, can't clobber it.
mov r4,r0
mov r5,r1
mov r6,r2
mov r0,r4
mov r1,r5
brafr7
.LPCS0:
mov r2,r6
I guess because the recently added "sibcall_value_pcrel_fdpic" pattern also
uses "=k" as the clobber constraint, it might run into the same problem. To
play safe for now, I'd like to commit the following to trunk and backport it to
5 and possibly 4.9:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 233324)
+++ gcc/config/sh/sh.md (working copy)
@@ -10476,12 +10476,16 @@
(const_string "single") (const_string "double")))
(set_attr "type" "jump_ind")])
+;; sibcall_value_pcrel used to have a =&k clobber for the scratch register
+;; that it needs for the branch address. This causes troubles when there
+;; is a big overlap of argument and return value registers. Hence, use a
+;; fixed call clobbered register for the address. See also PR 67260.
(define_insn_and_split "sibcall_value_pcrel"
[(set (match_operand 0 "" "=rf")
(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 +10495,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],
@@ -10505,6 +10511,8 @@
(const_string "single") (const_string "double")))
(set_attr "type" "jump_ind")])
+;; Like for sibcall_value_pcrel, use a fixed call clobbered register for
+;; the branch address.
(define_insn_and_split "sibcall_value_pcrel_fdpic"
[(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand"))
@@ -10511,7 +10519,7 @@
(match_operand 2)))
(use (reg:SI FPSCR_MODES_REG))
(use (reg:SI PIC_REG))
- (clobber (match_scratch:SI 3 "=k"))
+ (clobber (reg:SI R1_REG))
(return)]
"TARGET_SH2 && TARGET_FDPIC"
"#"
@@ -10520,6 +10528,8 @@
{
rtx lab = PATTERN (gen_call_site ());
+ operands[3] = gen_rtx_REG (SImode, R1_REG);
+
sh_expand_sym_label2reg (operands[3], operands[1], lab, true);
rtx i = emit_call_insn (gen_sibcall_valuei_pcrel_fdpic (operands[0],
operands[3],
Kaz, what do you think?
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #16 from Kazumoto Kojima --- (In reply to Rich Felker from comment #15) Maybe. There are other cases of address computations which could be shared or simplified, as you know. Again very restrictive branches and loads will make things hard.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #15 from Rich Felker --- Is it related to the fact that the relative address load is tied to a specific call site and that the call can't be cloned without producing a new relative address load to go with the clone?
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #14 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #13) > Good question indeed. Kaz, maybe you remember anything? With my vague recollection, they were already there when I had looked into them for the first time. I guess that SH jump stuff was built with stacking many things so to avoid strong restrictions of ISA. Rewriting them from a current view of gcc is a good thing, though perhaps it'll be a big hummer.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #13 from Oleg Endo --- (In reply to Alexander Monakov from comment #12) > > I mostly wonder why does sh.md change RTL representation of a sibcall that > way, instead of simply generating the required relative address load > upfront, during RTL expand. This way, RTL better matches final instruction > stream, register allocation should be more natural, and the load of the > relative address is subject to all RTL optimizations (so if you call a > function in a loop, you can load the relative address once, out of the loop). Good question indeed. Kaz, maybe you remember anything?
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #12 from Alexander Monakov --- > Do you have anything in particular in mind? I mostly wonder why does sh.md change RTL representation of a sibcall that way, instead of simply generating the required relative address load upfront, during RTL expand. This way, RTL better matches final instruction stream, register allocation should be more natural, and the load of the relative address is subject to all RTL optimizations (so if you call a function in a loop, you can load the relative address once, out of the loop).
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #11 from Oleg Endo --- (In reply to Alexander Monakov from comment #10) > If always using r0 is not an issue, I think it's possible to just use > operands[0] (casting it to the right size with subreg:SI, if needed) to > avoid using a potentially-reserved hardreg. This would allow to remove the > clobber from the pattern altogether. I'm not sure it's a good idea. All the call patterns are written with "=rf" for operand[0], i.e. it could be a floating point register. Under the current ABI all function calls always clobber GP regs r0..r3 though. To avoid more potential r0-spill-failure cases, I'd rather put the explicit r1 clobber. > (I also imagine that sh.md could benefit from a rework of call patterns, I > don't understand why it's done this way with postreload splits) Do you have anything in particular in mind? I guess some of the things are tied to the way constant/literal pools work on SH.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #10 from Alexander Monakov --- If always using r0 is not an issue, I think it's possible to just use operands[0] (casting it to the right size with subreg:SI, if needed) to avoid using a potentially-reserved hardreg. This would allow to remove the clobber from the pattern altogether. (I also imagine that sh.md could benefit from a rework of call patterns, I don't understand why it's done this way with postreload splits)
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-07 Ever confirmed|0 |1 --- Comment #9 from Oleg Endo --- (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.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #8 from Alexander Monakov --- 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. r0 is always suitable then and does not require mentioning in the RTL template, but constrains scheduling as Rich said. On the other hand, r1-r3 are also always suitable by virtue of being call-clobbered, and thus they wouldn't require a mention in the RTL template either.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #7 from Alexander Monakov --- Oleg, Rich, there's some confusion in comments 4-6. Please unwind all the way back to comment #1, and let me explain the issue once again. I now see that my phrasing back then was insufficiently detailed. Look at the RTL template I quote there, and note how it picks a register to hold relative callee address: 10484(clobber (match_scratch:SI 3 "=&k")) It then proceeds to specify how to emit a sequence of insns, first to load the address into operands[3] (the scratch reg above), and then to make a call using operands[3]. The split takes part after reload, so at the time of register allocation the instruction is not split and is represented by the RTL template as quoted. Note that there's no way to specify that the match_scratch reg is not going to be live simultaneously with operands[0], the return value. In fact, you can imagine that splitting emits some third instruction after the call that tries to use operands[3] and operands[0], and then there's no way to pick a scratch reg. So it's not like GCC is not doing something it should. It's sh.md that demands the impossible. This is why I suggested using a hard register in place of a scratch (because r0-r3 are free to use for that purpose anyway), but of course it has to be properly encoded in the RTL template: you'd clobber a specific hardreg instead of clobbering a scratch. Perhaps Rich misremembered something when saying that the chosen hardreg would not be explicit in the RTL. Does that clarify?
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #6 from Oleg Endo --- (In reply to Rich Felker from comment #5) > > 1. that the "k" constraint that's currently used is not working to > automatically assign a scratch register because r4-r7 are all live as > argument registers and r0-r3 are spuriously live as the return value, or > something like that, Yes, clearly something is not working as it should ... There are also similar issues with the R0-spill failures when adjacent instructions need R0 reloads. Have you tried using LRA (-mlra option)? > 2. that using a fixed register that's not represented at all in the RTL > constraints for sibcall_value_pcrel would work instead, and > 3. that if a fixed register is used, r1-r3 would be better choices than r0 > since r0 is special and some instructions (that could otherwise be scheduled > between the load of the target address and the actual call) have r0 > hard-coded as one of their operands. OK, now I get the idea. Using r1-r3 for this could be better, but probably it won't matter much. What I have observed is that for function calls, the function address is often loaded shortly before the branch instruction. Anyway, I don't think it's a good solution. It a trap for future development (e.g. ABI changes/extensions) and it could open another can of worms. For example, if you use r1 implicitly in the instruction without specifying it in the RTL, other optimizers will not see the r1 use and will potentially generate wrong code. I think that... > and GCC cannot know that the scratch reg > wouldn't be simultaneously live with those. .. this is the core issue here and that should be fixed instead.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #5 from Rich Felker --- Oleg, thanks for the tip. I think what Alexander is saying about r0-r3 is: 1. that the "k" constraint that's currently used is not working to automatically assign a scratch register because r4-r7 are all live as argument registers and r0-r3 are spuriously live as the return value, or something like that, 2. that using a fixed register that's not represented at all in the RTL constraints for sibcall_value_pcrel would work instead, and 3. that if a fixed register is used, r1-r3 would be better choices than r0 since r0 is special and some instructions (that could otherwise be scheduled between the load of the target address and the actual call) have r0 hard-coded as one of their operands. I'm still not sufficiently familiar with RTL to know if I got all that right, but hopefully it's at least close.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #4 from Oleg Endo ---
(In reply to Alexander Monakov from comment #1)
>
> So it wants to pick a scratch register in SIBCALL_REGS ("k", r0-r7), but in
> the circumstances r4-r7 are already used for argument passing, and r0-r3 are
> used for the return value -- and GCC cannot know that the scratch reg
> wouldn't be simultaneously live with those.
>
> I must say I don't quite see the point of using match_scratch for the callee
> address there. After all, it's making a sibcall, so GCC can simply pick r0
> or whatever's convenient, no?
I haven't checked the details of this issue, but generally, yes, It should be
able to pick r0...r3 for the scratch register in this case. At the time of the
call the values in r0...r3 are undefined and they get defined only after the
call. Not sure what's the problem here.
> In response to the last sentence in my analysis, on IRC Rich pointed out
> that using r1/r2/r3 should be better that r0 because some instruction can
> operate only on r0 so that would constrain scheduling.
Are there any examples for this statement?
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 Oleg Endo changed: What|Removed |Added Target||sh*-*-* --- Comment #3 from Oleg Endo --- This PR stayed under the radar because the target field was not filled in. Please fill in the target field of the PR as above next time you file bugs.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #2 from Alexander Monakov --- (added SH maintainers, Oleg Endo and Kaz Kojima to Cc) In response to the last sentence in my analysis, on IRC Rich pointed out that using r1/r2/r3 should be better that r0 because some instruction can operate only on r0 so that would constrain scheduling.
[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
With Rich's prompt I've looked at this issue for fun. Here's a minimal
testcase:
#pragma GCC visibility push(hidden)
double _Complex foo(double _Complex arg);
double _Complex bar(double _Complex arg)
{ return foo(arg); }
I could reproduce it with current (6.0) trunk with -O2 -m2a-nofpu -fPIC.
The issue, the way I see it, is sh.md does this:
10479 (define_insn_and_split "sibcall_value_pcrel"
10480 [(set (match_operand 0 "" "=rf")
10481 (call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
10482 (match_operand 2 "" "")))
10483(use (reg:SI FPSCR_MODES_REG))
10484(clobber (match_scratch:SI 3 "=&k"))
10485(return)]
10486 "TARGET_SH2 && !TARGET_FDPIC"
10487 "#"
10488 "reload_completed"
10489 [(const_int 0)]
10490 {
10491 rtx lab = PATTERN (gen_call_site ());
10492 rtx call_insn;
10493
10494 sh_expand_sym_label2reg (operands[3], operands[1], lab, true);
10495 call_insn = emit_call_insn (gen_sibcall_valuei_pcrel (operands[0],
10496 operands[3],
10497 operands[2],
10498 copy_rtx (lab)));
10499 SIBLING_CALL_P (call_insn) = 1;
10500 DONE;
10501 }
So it wants to pick a scratch register in SIBCALL_REGS ("k", r0-r7), but in the
circumstances r4-r7 are already used for argument passing, and r0-r3 are used
for the return value -- and GCC cannot know that the scratch reg wouldn't be
simultaneously live with those.
I must say I don't quite see the point of using match_scratch for the callee
address there. After all, it's making a sibcall, so GCC can simply pick r0 or
whatever's convenient, no?
