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
