diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2023-05-12 10:33:25 +0100 |
---|---|---|
committer | Tejas Belagod <tejas.belagod@arm.com> | 2025-04-08 11:50:49 +0530 |
commit | 001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18 (patch) | |
tree | c47e6812b3bfcb23414606e8d6be49ac750e193a /gcc/rust/backend | |
parent | 2b809d6f4fb62aeccf482a889bc2775e5d94ef80 (diff) | |
download | gcc-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