On Wed, 2012-03-21 at 13:57 +0000, Richard Earnshaw wrote:
> On 21/03/12 13:40, William J. Schmidt wrote:
> >
> > And it becomes even more difficult with more complex scenarios.
> > Consider:
> >
> > a = x + (3 * s);
> > b = x + (5 * s);
> > c = x + (7 * s);
> >
> > The framework I've developed recognizes that this group of instructions
> > is related, and that it is profitable to replace them as follows:
> >
> > a = x + (3 * s);
> > t = 2 * s;
> > b = a + t;
> > c = b + t;
> >
>
> Given that CPUs often have shift+add, that's not necessarily best
> either. Also, on pipelined super-scalar systems you're serializing a
> problem when it might be better to improve the parallelism.
>
> The best sequence on ARM would probably be something like
>
> a = x + (3 * s);
> b = a + (2 * s); (ADD b, a, s, LSL #1)
> c = a + (4 * s); (ADD b, a, s, LSL #2).
>

## Advertising

These are good points, and I hope you'll keep an eye on this work as it
proceeds. I should have been less categorical about stating the
profitability of the transformation. My intent is that the cost model
will reflect the capabilities of the target machine, and for the machine
I'm most familiar with the transformation as shown is best. Getting to
the optimal sequence that you show for ARM could be an interesting
challenge that might require additional logic in the cost model. I'll
add it to my list of things to think about.
Thanks,
Bill
>
> R.
>