On Tue, 22 Jul 2025, Richard Biener wrote:
> The following makes dataref analysis not set STMT_VINFO_VECTYPE.
> This leaves the field ready for taking when vectorizable_*
> transition to use SLP_TREE_VECTYPE. It also delays determining
> the vectorization mode a little bit - SLP build will first do
> that then. I have kept a check that there is any vector type
> for the scalar type in vect_analyze_data_refs, that handles
> early outs for aggregate and existing vector types.
This series also runs into RVV ICEs, like for
gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_32-1.c
we end up in
#0 0x000000000136d668 in tree_class_check (__t=<tree 0x0>,
__class=tcc_type, __f=0x47483d8
"/space/rguenther/src/gcc/gcc/config/riscv/riscv-vector-costs.cc",
__l=611, __g=0x4748f00
<riscv_vector::need_additional_vector_vars_p(_stmt_vec_info*)::__FUNCTION__>
"need_additional_vector_vars_p")
at /space/rguenther/src/gcc/gcc/tree.h:3877
#1 0x00000000025081c6 in riscv_vector::need_additional_vector_vars_p
(stmt_info=0x62be540)
at /space/rguenther/src/gcc/gcc/config/riscv/riscv-vector-costs.cc:611
#2 0x0000000002508b5e in riscv_vector::update_local_live_ranges
(vinfo=0x6139930, program_points_per_bb=..., live_ranges_per_bb=...,
biggest_mode=0x7fffffffbdac) at
/space/rguenther/src/gcc/gcc/config/riscv/riscv-vector-costs.cc:766
#3 0x0000000002509066 in riscv_vector::has_unexpected_spills_p
(loop_vinfo=0x6139930) at
/space/rguenther/src/gcc/gcc/config/riscv/riscv-vector-costs.cc:834
#4 0x00000000025094b9 in
riscv_vector::costs::record_potential_unexpected_spills (this=0x61f1d40,
loop_vinfo=0x6139930)
at /space/rguenther/src/gcc/gcc/config/riscv/riscv-vector-costs.cc:922
#5 0x0000000002509418 in riscv_vector::costs::analyze_loop_vinfo
(this=0x61f1d40, loop_vinfo=0x6139930)
at /space/rguenther/src/gcc/gcc/config/riscv/riscv-vector-costs.cc:904
where we access STMT_VINFO_VECTYPE (that's supposed to go away).
Basically all of costs::analyze_loop_vinfo would need to be re-done.
I also see it does compute post-dominators and scrap them for each
costing done! For larger functions with many loops that's going
to be slooooow (it's O(function-size)). I think of SPEC WRF here.
It's used only in max_number_of_live_regs which does
/* Collect user explicit RVV type. */
auto_vec<basic_block> all_preds
= get_all_dominated_blocks (CDI_POST_DOMINATORS, bb);
tree t;
FOR_EACH_SSA_NAME (i, t, cfun)
{
WTF does this do? We are processing a single loop [nest], we
are in LC SSA, why do we care for any SSA uses outside of
the loop body!? It _does_ all look like a property that
can be incrementally updated during the add_stmt hook calls?
I do wonder if anybody reviews this stuff to make sense :/
Richard.
> * tree-vect-data-refs.cc (vect_analyze_data_refs): Do not
> set STMT_VINFO_VECTYPE.
> ---
> gcc/tree-vect-data-refs.cc | 17 ++---------------
> 1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
> index b62498b34bd..89d5426bb11 100644
> --- a/gcc/tree-vect-data-refs.cc
> +++ b/gcc/tree-vect-data-refs.cc
> @@ -5242,10 +5242,9 @@ vect_analyze_data_refs (vec_info *vinfo, bool *fatal)
> STMT_VINFO_DR_STEP_ALIGNMENT (stmt_info));
> }
>
> - /* Set vectype for STMT. */
> + /* Check whether there is any vectype for STMT. */
> scalar_type = TREE_TYPE (DR_REF (dr));
> - tree vectype = get_vectype_for_scalar_type (vinfo, scalar_type);
> - if (!vectype)
> + if (! get_related_vectype_for_scalar_type (VOIDmode, scalar_type))
> {
> if (dump_enabled_p ())
> {
> @@ -5273,18 +5272,6 @@ vect_analyze_data_refs (vec_info *vinfo, bool *fatal)
> " scalar_type: %T\n",
> stmt_info->stmt, scalar_type);
> }
> - else
> - {
> - if (dump_enabled_p ())
> - dump_printf_loc (MSG_NOTE, vect_location,
> - "got vectype for stmt: %G%T\n",
> - stmt_info->stmt, vectype);
> - }
> -
> - /* Leave the BB vectorizer to pick the vector type later, based on
> - the final dataref group size and SLP node size. */
> - if (is_a <loop_vec_info> (vinfo))
> - STMT_VINFO_VECTYPE (stmt_info) = vectype;
>
> if (gatherscatter != SG_NONE)
> {
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
