Re: More type narrowing in match.pd

[Jeff Law <law@redhat.com>]

On 04/30/2015 03:38 PM, Marc Glisse wrote:
> On Thu, 30 Apr 2015, Jeff Law wrote:
>
>> On 04/30/2015 01:17 AM, Marc Glisse wrote:
>>>
>>> +/* This is another case of narrowing, specifically when there's an
>>> outer
>>> +   BIT_AND_EXPR which masks off bits outside the type of the innermost
>>> +   operands.   Like the previous case we have to convert the operands
>>> +   to unsigned types to avoid introducing undefined behaviour for the
>>> +   arithmetic operation.  */
>>> +(for op (minus plus)
>>>
>>> No mult? or widen_mult with a different pattern? (maybe that's already
>>> done elsewhere)
>> No mult.  When I worked on the pattern for 47477, supporting mult
>> clearly regressed the generated code -- presumably because we can
>> often widen the operands for free.
>
> It would help with the testcase below, but I am willing to accept that
> the cases where it hurts are more common (and guessing if it will help
> or hurt may be hard), while with +- the cases that help are more common.
>
> void f(short*a) {
>    a = __builtin_assume_aligned(a,128);
>    for (int i = 0; i < (1<<22); ++i) {
> #ifdef EASY
>      a[i] *= a[i];
> #else
>      int x = a[i];
>      x *= x;
>      a[i] = x;
> #endif
>    }
> }
Thanks.  I've filed a bug and attached it the operand 
shortening/narrowing BZ (65964).  I strongly suspect there's other bugs 
in BZ that need to be attached to 65964.

jeff