This is the mail archive of the
mailing list for the GCC project.
Re: [RFC]: Remove Mem/address type assumption in combiner
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- 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:01:20 -0500
- 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> <alpine dot BSF dot 2 dot 02 dot 1505161228380 dot 42482 at arjuna dot pair dot com>
On Sat, May 16, 2015 at 12:36:38PM -0400, Hans-Peter Nilsson wrote:
> 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.
With a plus or minus combine would always write it as a mult.
I don't think any other pass would create this combination. I
haven't tested it though.
> > > ("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.
The "unreachable" thing should quickly tell you if that guess is wrong.
Not something you want to leave in a production compiler, of course.
> > Looks like quite some work for you, I'm sorry about that,
> It's almost over, at least the editing part...
Great to hear that!