This is the mail archive of the 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: More type narrowing in match.pd

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
+   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];
     int x = a[i];
     x *= x;
     a[i] = x;
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.


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