[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

["olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(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.