On Wed, 3 Sep 2025, Tamar Christina wrote:
> If the user has requested loop unrolling through pragma GCC unroll then at the
> moment we only set LOOP_VINFO_USER_UNROLL if the vectorizer has not overrode
> the
> unroll factor (through backend costing) or if the VF made the requested unroll
> factor be 1.
>
> When we have a loop of say int and a pragma unroll 4
>
> If the vectorizer picks V4SI as the mode, the requested unroll ended up
> exactly
> matching the VF. As such the requested unroll is 1 and we don't clear the
> pragma.
>
> So it did honor the requested unroll factor. However since we didn't set the
> unroll amount back and left it at 4 the rtl unroller won't use the rtl cost
> model at all and just unroll the vector loop 4 times.
>
> But of these events are costing related, and so it stands to reason that we
> should set LOOP_VINFO_USER_UNROLL to we return the RTL unroller to use the
> backend costing for any further unrolling.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu,
> arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
> -m32, -m64 and no issues.
>
> Ok for master? Tests using this are in the next patch.
OK.
Thanks,
Richard.
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * tree-vect-loop.cc (vect_analyze_loop_1): If the unroll pragma was set
> mark it as handled.
> * doc/extend.texi (pragma GCC unroll): Update documentation.
>
> ---
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index
> 382295834035e48ea24b3ecbad8d61f9c37e4dc7..119dce79ebaf205aa4653af96e24c065facad509
> 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -10451,10 +10451,11 @@ loop or a @code{#pragma GCC ivdep}, and applies
> only to the loop that follows.
> @var{n} is an integer constant expression specifying the unrolling factor.
> The values of @math{0} and @math{1} block any unrolling of the loop.
>
> -If the loop was vectorized the unroll factor specified will be used to seed
> the
> -vectorizer unroll factor. Whether the loop is unrolled or not will be
> -determined by target costing. The resulting vectorized loop may still be
> -unrolled more in later passes depending on the target costing.
> +If the loop is vectorized the vectorizer considers extra unrolling to honor
> the
> +unroll factor. After vectorizing a loop the pragma is dropped. Whether the
> +loop is unrolled or not will be determined by target costing. The resulting
> +vectorized loop may still be unrolled more in later passes depending on the
> +target costing.
>
> @end table
>
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index
> fafd24c132eaade782bef5fd74cde8cb385d58a3..cf30e506e582d5486ab6f0f30ea27c1a34cf8c64
> 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -2952,11 +2952,13 @@ vect_analyze_loop_1 (class loop *loop,
> vec_info_shared *shared,
> {
> delete loop_vinfo;
> loop_vinfo = unroll_vinfo;
> - LOOP_VINFO_USER_UNROLL (loop_vinfo) = user_unroll > 1;
> }
> else
> delete unroll_vinfo;
> }
> +
> + /* Record that we have honored a user unroll factor. */
> + LOOP_VINFO_USER_UNROLL (loop_vinfo) = user_unroll > 1;
> }
>
> /* Remember the autodetected vector mode. */
>
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
