From: Richard Biener <richard.guenther@gmail.com>
To: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Cc: Andrew Pinski <pinskia@gmail.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: RFC: Two minor optimization patterns
Date: Wed, 14 Jan 2015 14:01:00 -0000 [thread overview]
Message-ID: <CAFiYyc3mduvq1xqLuj4zZ93Rf2PjbQqxF36Rj8nodAwAMHe9ig@mail.gmail.com> (raw)
In-Reply-To: <87sifdv9dk.fsf@rasmusvillemoes.dk>
On Wed, Jan 14, 2015 at 1:23 PM, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> On Wed, Jan 14 2015, Richard Biener <richard.guenther@gmail.com> wrote:
>
>> On Tue, Jan 13, 2015 at 11:47 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>>> On Tue, Jan 13, 2015 at 2:41 PM, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
>>>> [My first attempt at submitting a patch for gcc, so please forgive me
>>>> if I'm not following the right protocol.]
>>>
>>> There are a few things missing. For one, a testcase or two for the
>>> added optimizations.
>
> I'll see what I can come up with. Thanks for the pointers.
>
>>>> Sometimes rounding a variable to the next even integer is written x += x
>>>> & 1. This usually means using an extra register (and hence at least an
>>>> extra mov instruction) compared to the equivalent x = (x + 1) & ~1. The
>>>> first pattern below tries to do this transformation.
>>>>
>>>> While playing with various ways of rounding down, I noticed that gcc
>>>> already optimizes all of x-(x&3), x^(x&3) and x&~(x&3) to simply
>>>> x&~3.
>>
>> Does it also handle x+(x&3)?
>
> I'm not sure what 'it' refers to, and I'm also not sure how you think
> x+(x&3) could be rewritten.
I was just guessing.
>> Where does it handle x - (x&3)?
>
> If by 'it' you mean gcc, I tried looking for a pattern matching this,
> but couldn't find it, so I don't know where it is handled. I can just
> see by running gcc-5.0 -fdump-tree-original -O2 -c opt.c that "x - (x &
> 3)" is rewritten as x & -4 (which is of course the same as x & ~3).
That's done in fold-const.c:fold_binary_loc here:
/* Fold A - (A & B) into ~B & A. */
if (!TREE_SIDE_EFFECTS (arg0)
&& TREE_CODE (arg1) == BIT_AND_EXPR)
{
...
(note that patterns are not fully moved to match.pd yet)
> Btw,
> I now see that neither x&~(x&3) or x&~(x&y) are rewritten that early,
> but objdump -d shows that the end result is the same.
>
>> That is, doesn't the pattern also work for constants other than 1?
>
> Here I assume that 'the pattern' refers to the first pattern, and the
> answer is 'not immediately'. To round up a number to the next multiple
> of 2^k we need to add the negative of that number modulo 2^k. It just so
> happens that for k=1 we have x==-x for both possible values of x. So
> with a little tweak, this does in fact lead to an optimization
> opportunity, namely x + ((-x) & m) -> (x + m) & ~m whenever m is one
> less than a power of 2. I don't know how to check for m satisfying this
> in the match.pd language.
you'd need to write some C code involving trees in a if/with. We do
have a integer_pow2p predicate but not a integer_one_less_than_pow2p
one.
>
>> Please put it before the abs simplifications after the last one handing
>> bit_and/bit_ior.
>
> OK, will do.
Thanks,
Richard.
> Rasmus
next prev parent reply other threads:[~2015-01-14 13:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 22:47 Rasmus Villemoes
2015-01-13 22:56 ` Andrew Pinski
2015-01-14 9:52 ` Richard Biener
2015-01-14 12:45 ` Rasmus Villemoes
2015-01-14 14:01 ` Richard Biener [this message]
2015-01-21 10:50 ` [PATCH 0/4] A few " Rasmus Villemoes
2015-01-21 10:50 ` [PATCH 1/4] match.pd: Add x + (x & 1) -> (x + 1) & ~1 pattern Rasmus Villemoes
2015-04-30 9:34 ` Richard Biener
2015-05-01 18:26 ` Jeff Law
2015-01-21 10:55 ` [PATCH 2/4] match.pd: Add x & ~(x & y) -> x & ~y pattern Rasmus Villemoes
2015-05-01 18:29 ` Jeff Law
2015-01-21 10:58 ` [PATCH 3/4] match.pd: Add x | ~(x | y) -> x | " Rasmus Villemoes
2015-01-21 11:32 ` Marek Polacek
2015-01-21 11:17 ` [PATCH 4/4] match.pd: Add x + ((-x) & m) -> (x + m) & ~m pattern Rasmus Villemoes
2015-04-30 9:42 ` Richard Biener
2015-04-30 11:56 ` Marc Glisse
2015-04-30 12:25 ` Richard Biener
2015-01-14 13:14 ` RFC: Two minor optimization patterns Marc Glisse
2015-01-14 13:58 ` Richard Biener
2015-01-14 14:31 ` Marc Glisse
2015-01-14 14:49 ` Richard Biener
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=CAFiYyc3mduvq1xqLuj4zZ93Rf2PjbQqxF36Rj8nodAwAMHe9ig@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=pinskia@gmail.com \
--cc=rv@rasmusvillemoes.dk \
/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).