On 17/08/12 15:31, Richard Earnshaw wrote:
On 17/08/12 15:22, Andrew Stubbs wrote:
On 17/08/12 15:04, Richard Earnshaw wrote:
The fix is to make is_widening_mult_p note that it has been called with
a WIDEN_MULT_EXPR and rather than decompose the operands again, to
simply extract the existing operands, which have already been formulated
correctly for a widening multiply operation.
As long as the existing test cases work, I think the only problem with
this idea is if some architecture has a wider range of widening
multiply-and-accumulate than it does plain widening multiply.
But surely in that case step1 wouldn't have applied and we'd then be
looking at a MULT_EXPR not a WIDEN_MULT_EXPR.
Not necessarily.
For example, it will use a 32x32->64 signed widening multiply for 16 bit
unsigned data if there is no unsigned 16x16->64 option. Hypothetically,
if there happened to be an unsigned 16x16->64 multiply-and-accumulate
then you'd end up masking it.
Like I said though, cross that bridge if it ever comes to it.
Andrew
