This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [MIPS] MADD issue
Nigel Stephens <nigel@mips.com> 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