aboutsummaryrefslogtreecommitdiff
path: root/gcc/rust/backend
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2023-05-12 10:33:25 +0100
committerTejas Belagod <tejas.belagod@arm.com>2025-04-08 11:50:49 +0530
commit001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18 (patch)
treec47e6812b3bfcb23414606e8d6be49ac750e193a /gcc/rust/backend
parent2b809d6f4fb62aeccf482a889bc2775e5d94ef80 (diff)
downloadgcc-001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18.zip
gcc-001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18.tar.gz
gcc-001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18.tar.bz2
gomp: Various fixes for SVE types [PR101018]
Various parts of the omp code checked whether the size of a decl was an INTEGER_CST in order to determine whether the decl was variable-sized or not. If it was variable-sized, it was expected to have a DECL_VALUE_EXPR replacement, as for VLAs. This patch uses poly_int_tree_p instead, so that variable-length SVE vectors are treated like constant-length vectors. This means that some structures become poly_int-sized, with some fields at poly_int offsets, but we already have code to handle that. An alternative would have been to handle the data via indirection instead. However, that's likely to be more complicated, and it would contradict is_variable_sized, which already uses a check for TREE_CONSTANT rather than INTEGER_CST. gimple_add_tmp_var should probably not add a safelen of 1 for SVE vectors, but that's really a separate thing and might be hard to test. Co-authored-by: Tejas Belagod <tejas.belagod@arm.com> gcc/ PR middle-end/101018 * poly-int.h (can_and_p): New function. * fold-const.cc (poly_int_binop): Use it to optimize BIT_AND_EXPRs involving POLY_INT_CSTs. * gimplify.cc (omp_notice_variable): Use poly_int_tree_p instead of INTEGER_CST when checking for constant-sized omp data. (gimplify_adjust_omp_clauses_1): Likewise. (gimplify_adjust_omp_clauses): Likewise. * omp-low.cc (scan_sharing_clauses): Likewise.
Diffstat (limited to 'gcc/rust/backend')
0 files changed, 0 insertions, 0 deletions