https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #377 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #376)
> 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...
movsf_ie_rffr/2 is different with its SFmode clobber pattern from others.
They are similar but movsf_ie_rffr is generated only brfore RA. RA will see
the alternatives of the generated insn so they don't make RA confuse, I
thought. There could be problems for them, though.
>
> 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?
Maybe. There could be a lot of room for improvement.
