https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #376 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #374)
> Created attachment 59286 [details]
> a patch for c#367
>
> We use movsf_ie as a fall-back for for moving fp-reg from/to multiword
> subreg in 59190. Looks this confuses LRA with the SI mode scratch
> constrained to "y".
>
> The patch uses a new pattern instead of movsf_ie. It's a mini movsf_ie in a
> sense but with the SFmode scratch.
>
> (define_insn_and_split "movsf_ie_rffr"
> [(set (match_operand:SF 0 "arith_reg_dest" "=f,r,rf")
> (match_operand:SF 1 "arith_reg_operand" "f,r,fr"))
Alternative #2 above is the same as alternative #13 of the "movsf_ie" pattern,
isn't it?
.. which is also the same as "movsf_ie_y" and that dangling 'define_split'
below, which could be the reason for PR 116709.
I'm a bit concerned that all the different SFmode move constructs will get in
the way when trying to address PR 115949 (trouble with v2sf usage from fsca
insn), PR 13423, PR 55295...
Another thing in the "SH: Try to reduce R0 live ranges" patch, pattern
define_expand "mov<mode>":
> if (! lra_in_progress && ! reload_completed
> && sh_lra_p ()
> && ! TARGET_SH2A
> && arith_reg_operand (operands[1], <MODE>mode)
> && satisfies_constraint_Sid (operands[0]))
> {
> rtx adr = XEXP (operands[0], 0);
> rtx base = XEXP (adr, 0);
> rtx idx = XEXP (adr, 1);
> emit_insn (gen_mov<mode>_store_mem_index (base, idx,operands[1]));
> DONE;
> }
Doesn't this break mem aliasing info? Also the code added in "movsf" that does
a similar thing... AFAIR the proper way would be to use 'replace_equiv_address'
somehow?
