From: Segher Boessenkool <segher@kernel.crashing.org>
To: Hans-Peter Nilsson <hp@bitrange.com>
Cc: "Kumar, Venkataramanan" <Venkataramanan.Kumar@amd.com>,
"Jeff Law (law@redhat.com)" <law@redhat.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
"maxim.kuvyrkov@linaro.org" <maxim.kuvyrkov@linaro.org>
Subject: Re: [RFC]: Remove Mem/address type assumption in combiner
Date: Sat, 16 May 2015 14:36:00 -0000 [thread overview]
Message-ID: <20150516143238.GE7531@gate.crashing.org> (raw)
In-Reply-To: <alpine.BSF.2.02.1505152216400.41528@arjuna.pair.com>
On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote:
> I confess the test-case-"guarded" addi pattern should have been
> expressed with a shift in addition to the multiplication.
But they wouldn't ever match so they might very well have bitrotted
by now :-(
> ("In
> addition to" as the canonically wrong one used to be the
> combine-matching pattern; I'm not sure I should really drop that
> just yet.)
It is harmless to leave it in. It will rot though, eventually --
better take it out before then. Add some gcc_unreachable, perhaps.
> Supposedly more noteworthy: this now-stricter canonicalization
> leads to a requirement to rewrite patterns that used to be:
>
> (parallel
> [(set reg0 (mem (plus (mult reg1 N) reg2)))
> (set reg3 (plus (mult reg1 N) reg2))])
>
> into the awkwardly asymmetric:
>
> (parallel
> [(set reg0 (mem (plus (mult reg1 2) reg2)))
> (set reg3 (plus (ashift reg1 M) reg2))])
>
> (where M = log2 N)
Yeah. This is true of parallels in general: canonicalisation works
on each arm separately. I'm not sure what can be done about it.
Looks like quite some work for you, I'm sorry about that,
Segher
next prev parent reply other threads:[~2015-05-16 14:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-29 9:29 Kumar, Venkataramanan
2015-04-29 17:38 ` Segher Boessenkool
2015-04-29 19:23 ` Jeff Law
2015-05-01 15:18 ` Segher Boessenkool
2015-05-05 16:14 ` Kumar, Venkataramanan
2015-05-05 17:15 ` Segher Boessenkool
2015-05-07 11:01 ` Kumar, Venkataramanan
2015-05-11 17:50 ` Steve Ellcey
2015-05-11 18:27 ` Segher Boessenkool
2015-05-11 19:44 ` Steve Ellcey
2015-05-11 19:46 ` Jeff Law
2015-05-11 19:46 ` Jeff Law
2015-05-11 20:17 ` Matthew Fortune
2015-05-11 20:30 ` Segher Boessenkool
2015-05-11 20:54 ` Matthew Fortune
2015-05-12 6:43 ` Kumar, Venkataramanan
2015-05-12 16:57 ` Steve Ellcey
2015-05-12 22:02 ` Moore, Catherine
2015-05-16 6:09 ` Hans-Peter Nilsson
2015-05-16 14:36 ` Segher Boessenkool [this message]
2015-05-16 16:43 ` Hans-Peter Nilsson
2015-05-16 17:40 ` Segher Boessenkool
2015-05-17 8:53 ` Hans-Peter Nilsson
2015-05-17 13:32 ` Segher Boessenkool
2015-05-17 13:48 ` Hans-Peter Nilsson
2015-05-19 17:30 ` Jeff Law
2015-04-29 19:22 ` Jeff Law
2015-04-29 19:31 ` Jeff Law
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=20150516143238.GE7531@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=Venkataramanan.Kumar@amd.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hp@bitrange.com \
--cc=law@redhat.com \
--cc=maxim.kuvyrkov@linaro.org \
/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).