From: Richard Biener <richard.guenther@gmail.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Rasmus Villemoes <rv@rasmusvillemoes.dk>,
Andrew Pinski <pinskia@gmail.com>
Subject: Re: [PATCH 4/4] match.pd: Add x + ((-x) & m) -> (x + m) & ~m pattern
Date: Thu, 30 Apr 2015 12:25:00 -0000 [thread overview]
Message-ID: <CAFiYyc1mLSA7aSbKqoY8pXvhUy0C6Y4phRsNHUA1iQZj=rtNSA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1504301320130.9338@stedding.saclay.inria.fr>
On Thu, Apr 30, 2015 at 1:44 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Thu, 30 Apr 2015, Richard Biener wrote:
>
>> On Wed, Jan 21, 2015 at 11:49 AM, Rasmus Villemoes
>> <rv@rasmusvillemoes.dk> wrote:
>>>
>>> Generalizing the x+(x&1) pattern, one can round up x to a multiple of
>>> a 2^k by adding the negative of x modulo 2^k. But it is fewer
>>> instructions, and presumably requires fewer registers, to do the more
>>> common (x+m)&~m where m=2^k-1.
>>>
>>> Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
>>> ---
>>> gcc/match.pd | 9 ++++++
>>> gcc/testsuite/gcc.dg/20150120-4.c | 59
>>> +++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 68 insertions(+)
>>> create mode 100644 gcc/testsuite/gcc.dg/20150120-4.c
>>>
>>> diff --git gcc/match.pd gcc/match.pd
>>> index 47865f1..93c2298 100644
>>> --- gcc/match.pd
>>> +++ gcc/match.pd
>>> @@ -273,6 +273,15 @@ along with GCC; see the file COPYING3. If not see
>>> (if (TREE_CODE (@2) != SSA_NAME || has_single_use (@2))
>>> (bit_ior @0 (bit_not @1))))
>>>
>>> +/* x + ((-x) & m) -> (x + m) & ~m when m == 2^k-1. */
>>> +(simplify
>>> + (plus:c @0 (bit_and@2 (negate @0) CONSTANT_CLASS_P@1))
>>
>>
>> I think you want to restrict this to INTEGER_CST@1
>
>
> Is this only to make the following test easier (a good enough reason for me)
> or is there some fundamental reason why this transformation would be wrong
> for vectors?
Good question - I suppose it also works for vectors (well, the predicates
don't). for non-ingegers or complex ints we shouldn't arrive here as
we can't have bit_and for them. for pointers we can't have plus on them.
So yes, it makes the following tests easier. A TODO comment for vectors
might be appropriate (we'd simply need a predicate that can test for
all emlements being 2^k-1).
Richard.
>
>>> + (with { tree cst = fold_binary (PLUS_EXPR, TREE_TYPE (@1),
>>> + @1, build_one_cst (TREE_TYPE (@1))); }
>>
>>
>> We shouldn't dispatch to fold_binary in patterns. int_const_binop would
>> be the appropriate function to use - but what happens for @1 == INT_MAX
>> where @1 + 1 overflows? Similar, is this also valid for negative @1
>> and thus signed mask types? IMHO we should check whether @1
>> is equal to wi::mask (TYPE_PRECISION (TREE_TYPE (@1)) - wi::clz (@1),
>> false, TYPE_PRECISION (TREE_TYPE (@1)).
>>
>> As with the other patch a ChangeLog entry is missing as well as stating
>> how you tested the patch.
>>
>> Thanks,
>> Richard.
>>
>>> + (if ((TREE_CODE (@2) != SSA_NAME || has_single_use (@2))
>>> + && cst && integer_pow2p (cst))
>>> + (bit_and (plus @0 @1) (bit_not @1)))))
>
>
> --
> Marc Glisse
next prev parent reply other threads:[~2015-04-30 12:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 22:47 RFC: Two minor optimization patterns 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
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 [this message]
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='CAFiYyc1mLSA7aSbKqoY8pXvhUy0C6Y4phRsNHUA1iQZj=rtNSA@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).