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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=116932
           Keywords|                            |ra

--- Comment #366 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #365)
> Looks that LRA reloads r144 with the register in more general class and
> there is no constraint preventing it in the insn pattern:
> 
> (define_insn_and_split "atomic_fetch_<fetchop_name><mode>_soft_imask"
>   [(set (match_operand:QIHISI 0 "arith_reg_dest" "=&r")
>       (match_operand:QIHISI 1 "atomic_mem_operand_1" "=SraSdd"))
>    (set (match_dup 1)
>       (unspec:QIHISI
>         [(FETCHOP:QIHISI
>               (match_dup 1)
>               (match_operand:QIHISI 2 "<fetchop_predicate_1>"
>                                       "<fetchop_constraint_1_imask>"))]
>         UNSPEC_ATOMIC))
>    (clobber (reg:SI R0_REG))
>    (clobber (match_scratch:QIHISI 3 "=&r"))]
>   "TARGET_ATOMIC_SOFT_IMASK"
> 
> I'm not sure why LRA does that, but I suppose that the more general class of
> registers usually helps.
> 

Thanks for having a look.  I've created a separate PR 116932 for it, as it this
also happens with old reload, albeit under slightly different circumstances.

Even after adding a constraint that would allow GBR addressing, LRA would still
change it.

> Avoiding this may require a pattern that only allows GBR.
> A similar problem occurs with extend<mode>si2, for example, and the patch
> 59158 introduces a new pattern to avoid such reloads:
> 
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59158&action=diff#a/gcc/
> config/sh/sh.md_sec1
> 
> It may be that similar changes are needed even with R0-specific pass.

I'm afraid that this will explode into an unmaintainable clutter.  It's already
quite bad as it is.  If we need so many exceptions, then probably something's
really wrong.

Perhaps LRA should simply not touch operands which already have hard-regs
assigned to them, especially when the hard-regs were already there before
RA/LRA has started.  This would allow doing custom pre-RA passes, not only for
SH, but maybe also useful for others.

Reply via email to