Re: [MIPS] MADD issue

[Nigel Stephens <nigel@mips.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.
>   

OK, we'll have a think about that.

Thanks

Nigel