This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Jul 1, 2011 at 1:58 PM, Stubbs, Andrew <Andrew_Stubbs@mentor.com> wrote:
> On 28/06/11 17:37, Michael Matz wrote:
>>> 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).
>> Okay, then you really want to look through value-preserving conversions.
>>
>>> > ?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?
>> Same-sized signed<-> ?unsigned conversions aren't value preserving:
>> ? ?unsigned char c = 255; (signed char)c == -1; 255 != -1
>> unsigned -> ?larger sized signed is value preserving
>> ? ?unsigned char c = 255; (signed short)c == 255;
>> signed -> ?unsigned never is value preserving
>
> OK, so I've tried implementing this, and I find I hit against a problem:
>
> Given this test case:
>
> ? unsigned long long
> ? foo (unsigned long long a, signed char *b, signed char *c)
> ? {
> ? ? return a + *b * *c;
> ? }
>
> Those rules say that it should not be suitable for optimization because
> there's an implicit cast from signed int to unsigned long long.
>
> Without any widening multiplications allowed, GCC gives this code (for ARM):
>
> ? ldrsb ? r2, [r2, #0]
> ? ldrsb ? r3, [r3, #0]
> ? mul ? ? r2, r2, r3
> ? adds ? ?r0, r0, r2
> ? adc ? ? r1, r1, r2, asr #31
>
> This is exactly what a signed widening multiply-and-accumulate with
> smlalbb would have done!
>
> OK, so the types in the testcase are a bit contrived, but my point is
> that I want to be able to use the widening-mult instructions everywhere
> that they would produce the same output and gcc would otherwise, and gcc
> just doesn't seem that interested in signed<->unsigned conversions.
>
> So, I'm happy to put in checks to ensure that truncations are not
> ignore, but I'm really not sure what's the right thing to do with the
> extends and signedness switches.
>
> Any suggestions?

Well - some operations work the same on both signedness if you
just care about the twos-complement result.  This includes
multiplication (but not for example division).  For this special
case I suggest to not bother trying to invent a generic predicate
but do something local in tree-ssa-math-opts.c.

Richard.

> Andrew
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]