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. Richard
