Richard Sandiford wrote:
Nigel Stephens <[EMAIL PROTECTED]> writes:
While I agree with you philosophically, it feels like (b) might be quite
a major task. A number of optimisation passes which currently recognise
and MUL and PLUS separately (e.g. loop strength reduction) would now
need to be extended to handle the fused MULPLUS and MULSUB operators.
And although the reduction in instruction count due to your previous
change is good, what is it as a percentage of the total? After all it
only helps code which uses 64-bit integer types with a 32-bit ABI, which
is probably quite a small proportion of most real-life applications --
whereas for some algorithms the ability to use MADD is absolutely
critical to performance, and for them losing the ability to generate
MADD is a significant backward step for the compiler.
How about, as a workaround until (b) sees the light of day, we
reimplement adddi3 and subdi3 only (not the other di mode patterns),
qualified by ISA_HAS_MADD_MSUB. Perhaps they could also be implemented
more cleanly nowadays, using define_insn_and_split and/or a "#"
template, to avoid generating multi-instruction assembler sequences.
The old patterns had a define_split too. That wasn't really the problem.
If you don't want to add a tree code yet, it would still be possible to
add the optab and expand support, recognising mult-add sequences in a
similar way to how we recognise widening multiplies now. I feel at
least that's a step in the right direction.
OK, we'll have a think about that.
Thanks
Nigel
