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
prev parent 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).