From: Kyrill Tkachov <kyrylo.tkachov@arm.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
Richard Biener <rguenther@suse.de>
Subject: Re: [PATCH][RFC][match.pd] optimize (X & C) == N when C is power of 2
Date: Fri, 24 Jul 2015 09:31:00 -0000 [thread overview]
Message-ID: <55B2042F.6030700@arm.com> (raw)
In-Reply-To: <20150724090945.GJ1780@tucnak.redhat.com>
On 24/07/15 10:09, Jakub Jelinek wrote:
> On Fri, Jul 24, 2015 at 09:48:30AM +0100, Kyrill Tkachov wrote:
>>>> Bootstrapped and tested on arm, aarch64, x86_64.
>>> I think this is another case that, if at all, should be done during or right
>>> before RTL expansion and should test rtx costs.
>> Hmm, where would that be?
> That is up to discussions, all I'm saying is that match.pd when run on
> GENERIC and/or anywhere among GIMPLE passes that fold stuff is undesirable.
>
> In expr.c, with TER you can detect such patterns, in this case when
> expanding the comparison, but perhaps we want a *.pd file that would have
> rules that would be only GIMPLE and only enabled in a special pass right
> before (or very close to) expansion, that would perform such instruction
> selection.
Wild idea, but could it be considered to have target-specific
match.pd files that can be included in the main match.pd?
That way, targets would get the benefit of getting
the target-specific folding they benefit from at the very beginning
of compilation without stepping on other targets toes.
Kyrill
>
>> Ok, I am not familiar with sparc64. The constant is just a 1
>> in the sign bit orred with a continuous string of ones.
>> That's usually cheap on aarch64 but may not be so on other targets.
> It has been a long time since I've done anything on sparc64, but you can
> e.g. have a look at config/sparc/sparc.c (sparc_emit_set_const64)
> to clearly see that not all constants are equal cost, some are much more
> expensive. Seems sparc_rtx_cost does not model this accurrately, but that
> is a backend bug, so shouldn't affect the generic decisions. Sparc does not
> have a moddi3 pattern, so your transformation might still be a win there,
> except for -Os where it would be very bad code size pessimization.
>
> All I want to say is that on GIMPLE we usually perform transformations where
> simpler (fewer operations) is considered better, and for the same number of
> operations where one sequence might be better on one target and another on
> another target, supposedly we want some other infrastructure.
>
> Jakub
>
next prev parent reply other threads:[~2015-07-24 9:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 8:21 Kyrill Tkachov
2015-07-24 8:36 ` Jakub Jelinek
2015-07-24 8:54 ` Kyrill Tkachov
2015-07-24 9:09 ` Richard Biener
2015-07-24 9:09 ` Kyrill Tkachov
2015-07-24 9:22 ` Ramana Radhakrishnan
2015-07-24 9:16 ` Jakub Jelinek
2015-07-24 9:31 ` Kyrill Tkachov [this message]
2015-07-24 9:36 ` Richard Biener
2015-07-24 10:11 ` Jakub Jelinek
2015-07-24 10:25 ` Ramana Radhakrishnan
2015-07-24 18:44 ` Jeff Law
2015-07-27 8:17 ` Richard Biener
2015-07-27 16:00 ` Jeff Law
2015-07-25 2:37 ` Segher Boessenkool
2015-07-27 8:23 ` Kyrill Tkachov
2015-07-27 15:54 ` Segher Boessenkool
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=55B2042F.6030700@arm.com \
--to=kyrylo.tkachov@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=rguenther@suse.de \
/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).