Yet another attempt to solve multiplication by 11 and many (most?) other constants problem

[Roger Sayle]

On Wed, 18 Jan 2006, Jan Hubicka wrote:
> What do you think of this approach?

This looks good.  I agree that alg_add_factor and alg_sub_factor
shouldn't have a reduced latency, but that alg_add_t_m2 and
alg_sub_t_m2 should, but with the strange way we identify these
sequences currently its difficult to assign latency accurately.

My only technical comment on your "request for comment" patch is
that you're not using sub_cost and even replace a use of shiftsub_cost
with shiftadd_cost.  On x86, rtx_cost is currently the same for PLUS
and MINUS, but the middle-end should really allow the backend to
parameterize different "costs" for these operations.  Especially,
as shiftadd_cost and shiftsub_cost are different for i386? (but perhaps
not for other platforms).

I also like the Athlon peephole2 for lea decomposition, though I'm
curious where in the middle-end we're producing the non-canonical
PLUS operation.  There's nothing wrong with your splitter, I'm just
curious whether this is an issue that should be fixed in combine or
where ever we introduce (set (regA) (plus (regB) (regA))).

Finally, I've a minor concern about compile-time impact.  synth_mult
is already highly recursive and we've previously had PRs about the
time it takes to synthesize 29 insn sequences on the EV4 alpha.
Since then we've added much better result caching to synth_mult, so
it probably shouldn't be an issue.


But in summary, it all looks good.


Roger
--