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: Fri, 21 Oct 2022 11:13:57 +0200 [thread overview]
Message-ID: <21949711-b310-cec3-5317-480c55f36ba5@linux.ibm.com> (raw)
In-Reply-To: <CAFiYyc2hFNpnqyHUYEFM1DPXGUct4rn2zp329on0osc_SL45jw@mail.gmail.com>
> Do we have evidence that targets properly cost XOR vs SUB RTXen?
>
> It might actually be a reload optimization - when the constant is
> available in a register use 'sub', when it needs to be reloaded
> use 'xor'?
>
> That said, I wonder if the fallout of changing some SUB to XOR
> is bigger than the benefit when we do it early (missed combines, etc.)?
Regarding fallout I did a bootstrap and regtest for various backends
now. No change on Power9, s390x and aarch64. On x86 there is one
additional FAIL in pr78103-3.c:
unsigned long long
bar (unsigned int x)
{
return __CHAR_BIT__ * sizeof (unsigned int) - 1 - __builtin_clz (x);
}
is supposed to become
bsrl %edi, %eax
ret
but now is
bsrl %edi, %eax
xorl $31, %eax
xorq $31, %rax
ret
The x86 backend has various splitters catching and simplifying something
like
(xor (minus (const_int 63) (clz (match_operand))) (const_int 63))
to
(bsr ...).
From a quick glance, there are several combinations of 31, 63, xor, clz
which would need to be duplicated(?) to match against the changed
patterns. Perhaps xor is always cheaper on x86 and a simple change from
(minus (const_int 63) (...)) to (xor (const_int 63) (...)) would be
sufficient but this would still need to be reviewed separately.
Needing to keep both patterns (as neither minus nor xor can be
considered "more canonical" than the other) seems like an annoyance.
Regards
Robin
prev parent reply other threads:[~2022-10-21 9:14 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
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 [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=21949711-b310-cec3-5317-480c55f36ba5@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).