[patch] Fixed-point patch 8/10

Richard Sandiford richard@codesourcery.com
Tue Sep 11 09:25:00 GMT 2007

"Fu, Chao-Ying" <fu@mips.com> writes:
>> > My first thought was "why not do this in target-independent code?".
>> > I.e., if the target doesn't have an addMM3 pattern for some MM for
>> > which overflow is undefined, why not try generating ssaddMM3 or
>> > usaddMM3 instead, before falling back on an element-wise 
>> > implementation?
>> > Presumably the trick will be useful for other targets too.  
>> Or is the
>> > idea that, by keeping the rtl code as a PLUS rather than [US]S_PLUS,
>> > later optimisations might be able to take advantage of the 
>> > undefinedness?
>   Probably, but I don't know which optimization does this.
> And, maybe some targets don't want to do this, due to the cost of
> saturating instructions.  So, the target-independent code may need to
> check the cost to see if it is beneficial.

But AIUI, your patch is short-circuiting the target-independent code
that decomposes a vector operation into individual elementwise operations.
Is that right?  If so, it seems very unlikely that a target would provide
a saturating vector addition that's _more_ expensive than decomposing a
vector into elements, performing addition on each pair of elements,
and reconstituting the vector.

>   The advantage of using the target-dependent method is that it makes 
> middle-end code simple and clean.  Each target can decide to create the
> instruction patterns or not.

I'm not sure I buy that argument either TBH.  There are various examples
of non-fixed-point operations that the middle-end code can expand in
different ways, depending on the capabilities of the target.  The approach
has generally been that a standard trick should be implemented once in the
middle end rather than several times across the target code.

I'm really playing Devil's Advocate here; I'm not totally opposed to
the extra patterns.


More information about the Gcc-patches mailing list