On Tue, Mar 18, 2025 at 11:27:06AM +0530, Tejas Belagod wrote:
> From: Richard Sandiford <[email protected]>
>
> 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 <[email protected]>
>
> 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.
Ok.
Jakub
