This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC]: Remove Mem/address type assumption in combiner
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: "Kumar, Venkataramanan" <Venkataramanan dot Kumar at amd dot com>, "Jeff Law (law at redhat dot com)" <law at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "maxim dot kuvyrkov at linaro dot org" <maxim dot kuvyrkov at linaro dot org>
- Date: Sat, 16 May 2015 12:36:38 -0400 (EDT)
- Subject: Re: [RFC]: Remove Mem/address type assumption in combiner
- Authentication-results: sourceware.org; auth=none
- References: <7794A52CE4D579448B959EED7DD0A4723DCE9F34 at satlexdag06 dot amd dot com> <20150429170335 dot GB21715 at gate dot crashing dot org> <20150501151758 dot GA1182 at gate dot crashing dot org> <alpine dot BSF dot 2 dot 02 dot 1505152216400 dot 41528 at arjuna dot pair dot com> <20150516143238 dot GE7531 at gate dot crashing dot org>
On Sat, 16 May 2015, Segher Boessenkool wrote:
> 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 :-(
It seems you're saying that the canonicalization to "ashift"
didn't work *at all*, when starting with an expression from an
address? I knew it failed in part, but always thought it was
just a partial failure.
> > ("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.
I've been trying to come up with valid reasons there'd be ever
be canonicalization by multiplication, but failed so I guess
I'll rip it out.
> > 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,
It's almost over, at least the editing part...
brgds, H-P