Re: [MIPS] MADD issue

[Nigel Stephens <nigel at mips dot com>]

Richard Sandiford wrote:
> 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

I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris, 
mcore, score, arm & pa backends still implement adddi3 as either a 
define_insn which outputs two instructions or an explicit define_expand 
followed define_split and associated sub patterns.  Are we setting the 
bar too high for MIPS? :)

Whilst I'm sure that your proposal is the right one going forward, it 
still feels like it could be significant amount of work to implement. 
And the simplified optab/expand support would only work for multiply-add 
sequences expressed within a single expression, and wouldn't be able to 
optimise disjoint multiply, then add expressions. Or have I missed 
something.

in the short term we really do need to reenable madd/msub for MIPS32 
targets in GCC 4. We could do that with a local patch to put back 
adddi3, but it would be better if we could coordinate this with you.

Nigel