[PATCH (3/7)] Widening multiply-and-accumulate pattern matching

Andrew Stubbs andrew.stubbs@gmail.com
Tue Jun 28 16:48:00 GMT 2011


On 28/06/11 16:53, Michael Matz wrote:
> On Tue, 28 Jun 2011, Richard Guenther wrote:
>> I'd name the predicate value_preserving_conversion_p which I think is
>> what you mean.  harmless isn't really descriptive.
>>
>> Note that you include non-value-preserving conversions, namely int ->
>> unsigned int.
>
> It seems that Andrew really does want to accept them.  If so
> value_preserving_conversion_p would be the wrong name.  It seems to me he
> wants to accept those conversions that make it possible to retrieve the
> old value, i.e. when "T1 x; (T1)(T2)x == x", then T1->T2 has the
> to-be-named property.  bits_preserving?  Hmm.

What I want (and I'm not totally clear on what this actually means) is 
to be able to optimize all the cases where the end result will be the 
same as the compiler produces now (using multiple multiply, shift, and 
add operations).

Ok, so that's an obvious statement, but the point is that, right now, 
the compiler does nothing special when you cast from int -> unsigned 
int, or vice-versa, and I want to capture that somehow. There are some 
exceptions, I'm sure, but what are they?

What is clear is that I don't want to just assume that casting from one 
signedness to the other is a show-stopper.

For example:

   unsigned long long
   foo (unsigned long long a, unsigned char b, unsigned char c)
   {
     return a + b * c;
   }

This appears to be entirely unsigned maths with plenty of spare 
precision, and therefore a dead cert for any SI->DI 
multiply-and-accumulate instruction, but not so - it is represented 
internally as:

   signed int tmp = (signed int)a * (signed int)b;
   unsigned long long result = a + (unsigned long long)tmp;

Notice the unexpected signed int in the middle! I need to be able to get 
past that to optimize this properly.

I've tried various test cases in which I cast signedness and mode around 
a bit, and so far it appear to perform safely, but probably I'm not be 
cunning enough.

Andrew



More information about the Gcc-patches mailing list