public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Hongtao Liu <crazylht@gmail.com>,
	Eric Botcazou <ebotcazou@libertysurf.fr>,
	Jeff Law <jeffreyalaw@gmail.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] regcprop: Fix another cprop_hardreg bug [PR100342]
Date: Fri, 14 May 2021 10:09:24 +0100	[thread overview]
Message-ID: <mpty2chy94r.fsf@arm.com> (raw)
In-Reply-To: <20210513170102.GQ3748@tucnak> (Jakub Jelinek's message of "Thu,  13 May 2021 19:01:02 +0200")

Jakub Jelinek <jakub@redhat.com> writes:
> On Thu, May 13, 2021 at 05:37:36PM +0200, Jakub Jelinek wrote:
>> So, do you want something like (I've deleted the old comment as I think
>> the new one is enough, but am open to keep both) the patch below, where
>> it REG_CAN_CHANGE_MODE_P is false, we punt (return), otherwise call
>> set_value_regno?
>> Am not sure if those REG_CAN_CHANGE_MODE_P arguments is what you want
>> though.
>
> Oops, missing !, meant following which works on 11 branch for the testcase:
>
> 2021-05-13  Jakub Jelinek  <jakub@redhat.com>
>
> 	PR rtl-optimization/100342
> 	* regcprop.c (copy_value): When copying a source reg in a wider
> 	mode than it has recorded for the value, adjust recorded destination
> 	mode too or punt if !REG_CAN_CHANGE_MODE_P.
>
> 	* gcc.target/i386/pr100342.c: New test.
>
> --- gcc/regcprop.c.jj	2021-03-23 10:21:07.176447920 +0100
> +++ gcc/regcprop.c	2021-05-13 17:36:46.443192451 +0200
> @@ -358,34 +358,25 @@ copy_value (rtx dest, rtx src, struct va
>    else if (sn > hard_regno_nregs (sr, vd->e[sr].mode))
>      return;
>  
> -  /* It is not safe to link DEST into the chain if SRC was defined in some
> -     narrower mode M and if M is also narrower than the mode of the first
> -     register in the chain.  For example:
> -     (set (reg:DI r1) (reg:DI r0))
> -     (set (reg:HI r2) (reg:HI r1))
> -     (set (reg:SI r3) (reg:SI r2)) //Should be a new chain start at r3
> -     (set (reg:SI r4) (reg:SI r1))
> -     (set (reg:SI r5) (reg:SI r4))
> -
> -     the upper part of r3 is undefined.  If we added it to the chain,
> -     it may be used to replace r5, which has defined upper bits.
> -     See PR98694 for details.
> -
> -     [A] partial_subreg_p (vd->e[sr].mode, GET_MODE (src))
> -     [B] partial_subreg_p (vd->e[sr].mode, vd->e[vd->e[sr].oldest_regno].mode)
> -     Condition B is added to to catch optimization opportunities of
> -
> -     (set (reg:HI R1) (reg:HI R0))
> -     (set (reg:SI R2) (reg:SI R1)) // [A]
> -     (set (reg:DI R3) (reg:DI R2)) // [A]
> -     (set (reg:SI R4) (reg:SI R[0-3]))
> -     (set (reg:HI R5) (reg:HI R[0-4]))
> -
> -     in which all registers have only 16 defined bits.  */
> -  else if (partial_subreg_p (vd->e[sr].mode, GET_MODE (src))
> -	   && partial_subreg_p (vd->e[sr].mode,
> -				vd->e[vd->e[sr].oldest_regno].mode))
> -    return;
> +  /* If a narrower value is copied using wider mode, the upper bits
> +     are undefined (could be e.g. a former paradoxical subreg).  Signal
> +     in that case we've only copied value using the narrower mode.
> +     Consider:
> +     (set (reg:DI r14) (mem:DI ...))
> +     (set (reg:QI si) (reg:QI r14))
> +     (set (reg:DI bp) (reg:DI r14))
> +     (set (reg:DI r14) (const_int ...))
> +     (set (reg:DI dx) (reg:DI si))
> +     (set (reg:DI si) (const_int ...))
> +     (set (reg:DI dx) (reg:DI bp))
> +     The last set is not redundant, while the low 8 bits of dx are already
> +     equal to low 8 bits of bp, the other bits are undefined.  */
> +  else if (partial_subreg_p (vd->e[sr].mode, GET_MODE (src)))
> +    {
> +      if (!REG_CAN_CHANGE_MODE_P (sr, GET_MODE (src), vd->e[sr].mode))
> +	return;

LGTM, but for extra safety, I think we also want:

   || !REG_CAN_CHANGE_MODE_P (dr, vd->e[sr].mode, GET_MODE (dst))

i.e. we're effectively converting the source from the wider mode
to the narrower mode, doing a move, and then converting the narrow
mode back to the wider mode.

OK with that change, thanks.

Richard

      reply	other threads:[~2021-05-14  9:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18  9:16 [PATCH] [PR rtl/optimization/98694] Fix incorrect optimization by cprop_hardreg Hongtao Liu
2021-01-18 10:18 ` Richard Sandiford
2021-01-18 10:43   ` Hongtao Liu
2021-01-18 10:51     ` Hongtao Liu
2021-01-18 11:10     ` Richard Sandiford
2021-01-19  0:59       ` Hongtao Liu
2021-01-19 12:38         ` Richard Sandiford
2021-01-19 14:45           ` Jakub Jelinek
2021-01-19 16:10             ` Richard Sandiford
2021-01-20  4:35               ` Hongtao Liu
2021-01-20  4:40                 ` Hongtao Liu
2021-01-20 12:56                 ` H.J. Lu
2021-01-20 14:14                 ` Richard Sandiford
2021-01-21  5:25                   ` Hongtao Liu
2021-05-05 17:44               ` [PATCH] regcprop: Fix another cprop_hardreg bug [PR100342] Jakub Jelinek
2021-05-06  8:50                 ` Jakub Jelinek
2021-05-11 10:59                 ` Richard Sandiford
2021-05-13 15:37                   ` Jakub Jelinek
2021-05-13 17:01                     ` Jakub Jelinek
2021-05-14  9:09                       ` Richard Sandiford [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mpty2chy94r.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=crazylht@gmail.com \
    --cc=ebotcazou@libertysurf.fr \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).