aboutsummaryrefslogtreecommitdiff
path: root/gcc/config
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2022-10-21 09:16:44 +0200
committerJakub Jelinek <jakub@redhat.com>2022-10-21 09:16:44 +0200
commitfa553ff26d96f6fecaa8f1b00649cfdc6cda5f5a (patch)
tree73b01534239c4297b3bf9675bd94d9487b5d0534 /gcc/config
parent5f9fac6ca86458ef21ab91ca471429d63f954003 (diff)
downloadgcc-fa553ff26d96f6fecaa8f1b00649cfdc6cda5f5a.zip
gcc-fa553ff26d96f6fecaa8f1b00649cfdc6cda5f5a.tar.gz
gcc-fa553ff26d96f6fecaa8f1b00649cfdc6cda5f5a.tar.bz2
match.pd: Fix up gcc.dg/pr54346.c on i686-linux [PR54346]
The pr54346.c testcase FAILs on i686-linux (without -msse*) for multiple reasons. One is the trivial missing -Wno-psabi which the following patch adds, but that isn't enough. The thing is that without native vector support, we have VEC_PERM_EXPRs in the IL and are actually considering the nested VEC_PERM_EXPRs into one VEC_PERM_EXPR optimization, but punt because can_vec_perm_const_p (result_mode, op_mode, sel2, false) is false. Such a test makes sense to prevent "optimizing" two VEC_PERM_EXPRs that can be handled by the backend natively into one VEC_PERM_EXPR that can't be handled. But if both of the original VEC_PERM_EXPRs can't be handled natively either, having just one VEC_PERM_EXPR that will be lowered by generic vec lowering is IMHO still better than 2. Or even if we trade just one VEC_PERM_EXPR that can't be handled plus one that can to one that can't be handled. Also, removing the testcase's executable permissions... 2022-10-21 <jakub@redhat.com> PR tree-optimization/54346 * match.pd ((vec_perm (vec_perm@0 @1 @2 VECTOR_CST) @0 VECTOR_CST)): Optimize nested VEC_PERM_EXPRs even if target can't handle the new one provided we don't increase number of VEC_PERM_EXPRs the target can't handle. * gcc.dg/pr54346.c: Add -Wno-psabi to dg-options.
Diffstat (limited to 'gcc/config')
0 files changed, 0 insertions, 0 deletions