From: Segher Boessenkool <segher@kernel.crashing.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Roger Sayle <roger@nextmovesoftware.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [x86 PATCH] PR rtl-optimization/96692: ((A|B)^C)^A using andn with -mbmi.
Date: Mon, 27 Jun 2022 10:03:51 -0500 [thread overview]
Message-ID: <20220627150351.GZ25951@gate.crashing.org> (raw)
In-Reply-To: <CAFULd4bqesr_QcjkKVLN53Lxbx-rV57kk3bhyOag36oTwFwFGQ@mail.gmail.com>
Hi!
On Sun, Jun 26, 2022 at 07:07:35PM +0200, Uros Bizjak via Gcc-patches wrote:
> On Sun, Jun 26, 2022 at 2:04 PM Roger Sayle <roger@nextmovesoftware.com> wrote:
> > I'll investigate whether this optimization can also be implemented
> > more generically in simplify_rtx when the backend provides
> > accurate rtx_costs for "(and (not ..." (as there's no optab for
> > andn).
"Accurate rtx_cost" is a fallacy. insn_cost can be seen as somewhat
accurate (in some simplified model of reality), but rtx_cost always
misses too much context to be useful as anything but a rough estimate.
> *combine splitter is described in the documentation as the splitter
> pattern that does *not* match any existing insn pattern.
Yeah, that documentation is somewhat misleading, in both directions :-(
combine can and will and does use any splitter, whether or not there is
an insn with that insn pattern. If there is an insn that passes recog()
combine will not even try a split, but this is not the same thing at
all: if the insn conditions are not met, the insn does not recog(). It
is quite common to have the same instruction pattern with different
insn conditions.
In the other direction, other passes can call split_insns as well, of
course. Nothing currently does, but that does not change much :-)
Segher
next prev parent reply other threads:[~2022-06-27 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-26 12:04 Roger Sayle
2022-06-26 17:07 ` Uros Bizjak
2022-06-27 15:03 ` Segher Boessenkool [this message]
2022-07-04 17:27 ` Roger Sayle
2022-07-04 18:51 ` Uros Bizjak
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=20220627150351.GZ25951@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=roger@nextmovesoftware.com \
--cc=ubizjak@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).