From: Robin Dapp <rdapp@linux.ibm.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Andrew Pinski <pinskia@gmail.com>
Subject: Re: [PATCH] expand: Convert cst - x into cst xor x.
Date: Tue, 6 Sep 2022 16:01:52 +0200 [thread overview]
Message-ID: <938fbb10-926f-a588-1e90-1d7b72d1d7f8@linux.ibm.com> (raw)
In-Reply-To: <CAFiYyc2Fh+Dw78nc5vJ-KEbf+QnwkGgYKBwtxQEgD+xiVfKptg@mail.gmail.com>
> cost might also depend on the context in case flag setting
> behavior differs for xor vs sub (on x86 sub looks strictly more
> powerful here). The same is probably true when looking for
> a combination with another bitwise operation.
>
> Btw, why not perform the optimization in expand_binop? That
> for example already does
>
> if (binoptab == sub_optab && CONST_INT_P (op1))
> {
> op1 = negate_rtx (mode, op1);
> binoptab = add_optab;
> }
>
> alternatively a targets expander can do the selection as well.
I was under the impression optabs/expand_binops is only supposed to
"optimize" when it's clear that it is an optimization/canonicalization.
I didn't see other functions there trying two alternatives and also none
seems to use range information already.
Regarding the proper costing (including the surroundings): is it even
possible to encompass everything in such a localized decision? A
target's expander decision would also not take this into account when
deciding? If so, should we not perform this conversion generally and not
only target specifc?
Regards
Robin
next prev parent reply other threads:[~2022-09-06 14:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 9:42 Robin Dapp
2022-09-06 12:31 ` Richard Biener
2022-09-06 14:01 ` Robin Dapp [this message]
2022-09-07 12:08 ` Richard Biener
2022-09-07 12:20 ` Robin Dapp
2022-09-07 12:45 ` Richard Biener
2022-09-07 16:30 ` Jeff Law
2022-10-21 9:13 ` Robin Dapp
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=938fbb10-926f-a588-1e90-1d7b72d1d7f8@linux.ibm.com \
--to=rdapp@linux.ibm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=pinskia@gmail.com \
--cc=richard.guenther@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).