public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Eric Botcazou <botcazou@adacore.com>,
	gcc-patches@gcc.gnu.org, Richard Biener <rguenther@suse.de>,
	Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040]
Date: Mon, 10 Apr 2023 09:10:59 +0200	[thread overview]
Message-ID: <ZDO2g7hYvMCJlIn4@tucnak> (raw)
In-Reply-To: <8d3c3861-c291-e762-a2a8-0b520f39a7e3@gmail.com>

On Sat, Apr 08, 2023 at 06:25:32PM -0600, Jeff Law wrote:
> 
> 
> On 4/6/23 08:21, Eric Botcazou wrote:
> 
> > > So, perhaps just in the return op0; case add further code for
> > > WORD_REGISTER_OPERATIONS and sub-word modes which will call nonzero_bits
> > > again for the word mode and decide if it is still safe.
> > 
> > Does it work to just replace mode by word_mode in the calls to nonzero_bits?
> It helps marginally -- basically we defer mucking up the code a bit.  We
> then hit this in simplify_and_const_int_1:
> 
> 
>   /* See what bits may be nonzero in VAROP.  Unlike the general case of
>      a call to nonzero_bits, here we don't care about bits outside
>      MODE.  */
> 
>   nonzero = nonzero_bits (varop, mode) & GET_MODE_MASK (mode);
> 
> That just seems wrong for WORD_REGISTER_OPERATIONS targets.
> 
> 
> Hacking both locations in a similar manner fixes the test.

If so, can you post that in patch form and can we go with that version
plus the testcase (e.g. from the first patch I've posted where I've changed
dse)?

	Jakub


  reply	other threads:[~2023-04-10  7:11 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05  9:16 [PATCH] dse: Handle SUBREGs of word REGs differently " Jakub Jelinek
2023-04-05 13:14 ` Jeff Law
2023-04-05 14:51   ` Jakub Jelinek
2023-04-05 16:17     ` Jeff Law
2023-04-05 16:48       ` Jakub Jelinek
2023-04-05 17:31         ` Jeff Law
2023-04-06  9:31           ` Richard Sandiford
2023-04-06  9:37             ` Li, Pan2
2023-04-06 14:49               ` Jeff Law
2023-04-06 14:45             ` Jeff Law
2023-04-06 10:15           ` Eric Botcazou
2023-04-06 10:31             ` [PATCH] combine: Fix simplify_comparison AND handling " Jakub Jelinek
2023-04-06 10:51               ` Eric Botcazou
2023-04-06 11:37                 ` Jakub Jelinek
2023-04-06 14:21                   ` Eric Botcazou
2023-04-09  0:25                     ` Jeff Law
2023-04-10  7:10                       ` Jakub Jelinek [this message]
2023-04-12  1:26                         ` Jeff Law
2023-04-12  6:21                           ` Jakub Jelinek
2023-04-12 10:02                             ` [PATCH] combine, v3: Fix " Jakub Jelinek
2023-04-12 14:17                               ` Jeff Law
2023-04-12 14:30                                 ` Jakub Jelinek
2023-04-12 15:24                               ` Segher Boessenkool
2023-04-12 16:58                               ` [PATCH] combine, v4: " Jakub Jelinek
2023-04-13  4:05                                 ` Jeff Law
2023-04-13 10:57                                   ` Segher Boessenkool
2023-04-13 12:35                                     ` Jeff Law
2023-04-13 13:45                                       ` [PATCH] loop-iv: Fix up bounds computation Jakub Jelinek
2023-04-13 15:07                                         ` Jeff Law
2023-04-13 19:37                                         ` Jeff Law
2023-04-12 13:29                             ` [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040] Jeff Law
2023-04-09  1:15                   ` Jeff Law
2023-04-10  5:13                     ` Hongtao Liu
2023-04-10  5:15                       ` Hongtao Liu
2023-04-06 14:35               ` Jeff Law
2023-04-06 15:06               ` Jeff Law
2023-04-06 14:53             ` [PATCH] dse: Handle SUBREGs of word REGs differently " Jeff Law

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=ZDO2g7hYvMCJlIn4@tucnak \
    --to=jakub@redhat.com \
    --cc=botcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=rguenther@suse.de \
    --cc=richard.sandiford@arm.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).