diff options
author | Jakub Jelinek <jakub@redhat.com> | 2021-09-01 13:30:51 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2021-09-01 13:40:43 +0200 |
commit | bea07159d1d4c9a61c8f7097e9f88c2b206b1b2f (patch) | |
tree | 9df5780b3d76c871dc729f73b17152c3fcb2a76f /gcc/objc/objc-act.c | |
parent | a61623d9b38d28048ccbd397d4ccf52c2dfb3fed (diff) | |
download | gcc-bea07159d1d4c9a61c8f7097e9f88c2b206b1b2f.zip gcc-bea07159d1d4c9a61c8f7097e9f88c2b206b1b2f.tar.gz gcc-bea07159d1d4c9a61c8f7097e9f88c2b206b1b2f.tar.bz2 |
vectorizer: Fix up vectorization using WIDEN_MINUS_EXPR [PR102124]
The following testcase is miscompiled on aarch64-linux at -O3 since the
introduction of WIDEN_MINUS_EXPR.
The problem is if the inner type (half_type) is unsigned and the result
type in which the subtraction is performed (type) has precision more than
twice as larger as the inner type's precision.
For other widening operations like WIDEN_{PLUS,MULT}_EXPR, if half_type
is unsigned, the addition/multiplication result in itype is also unsigned
and needs to be zero-extended to type.
But subtraction is special, even when half_type is unsigned, the subtraction
behaves as signed (also regardless of whether the result type is signed or
unsigned), 0xfeU - 0xffU is -1 or 0xffffffffU, not 0x0000ffff.
I think it is better not to use mixed signedness of types in
WIDEN_MINUS_EXPR (have unsigned vector of operands and signed result
vector), so this patch instead adds another cast to make sure we always
sign-extend the result from itype to type if type is wider than itype.
2021-09-01 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/102124
* tree-vect-patterns.c (vect_recog_widen_op_pattern): For ORIG_CODE
MINUS_EXPR, if itype is unsigned with smaller precision than type,
add an extra cast to signed variant of itype to ensure sign-extension.
* gcc.dg/torture/pr102124.c: New test.
Diffstat (limited to 'gcc/objc/objc-act.c')
0 files changed, 0 insertions, 0 deletions