On 05/16/2015 07:55 PM, Hans-Peter Nilsson wrote:
On Sat, 16 May 2015, Segher Boessenkool wrote:
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.
Ports probably also generate that internally at various RTL
passes, something that takes a bit more than an at-a-glance code
inspection.
Correct. THe PA port for example has a ton of this kind of RTL
rewriting to exploit the shift-add insns and scaled indexed addressing
modes (and correct for some oddities in the PA chip where the scaled
modes don't exist in every context where you'd think they should).
And you still have to to worry about things like combine taking a (mem
(plus (mult))), selecting the (plus (mult)) as a split point and failing
to canonicalize it into the ashift form.
I ran into that while fixing up the PA for these changes. The good news
is with two trivial combine changes and the expected changes to the PA
backend, I can get code generation back to where it was before across my
sample testfiles.
Jeff
