[PATCH v4 1/3] gomp: Various fixes for SVE types [PR101018]

[Jakub Jelinek]

On Tue, Mar 18, 2025 at 11:27:06AM +0530, Tejas Belagod wrote:
> From: Richard Sandiford <richard.sandiford@arm.com>
> 
> 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.

Ok.

	Jakub