Re: [PATCH] tree-optimization: Fold CDCE {0, N} memset through arbitrary pointers [PR102202]

Jeffrey Law <[email protected]>
Newsgroups gmane.comp.gcc.patches
Message-ID <[email protected]>

On 7/17/2026 12:20 AM, Naveen wrote:
> CDCE already recognizes an exact two-value length range {0, N}, guards the
> zero-length path and replaces the length on the nonzero path with N and folds
> the call again.  The accepted PR102202 fold handles N == 1 through arbitrary
> pointer destinations but the guarded {0, N} path still needs the same
> scalar-store conversion for supported N greater than one.
>
> Keep normal builtin folding behavior unchanged: ordinary constant-size memsets
> are still left to the existing ADDR_EXPR/object-specific machinery.  Expose the
> memset fold with an opt-in flag for multi-byte arbitrary-pointer stores and
> let CDCE use that flag only after it has shrink-wrapped the zero-length path
> and pinned the guarded length to N.
>
> The multi-byte fold keeps the existing object-size deferral and bounds checks.
> It limits the store to MOVE_MAX, requires an exact integer/bitwise mode, checks
> unaligned-store support and replicates the fill byte into the selected scalar
> type.
>
> gcc/ChangeLog:
>
> 	PR tree-optimization/102202
> 	* gimple-fold.cc (gimple_fold_builtin_memset): Make non-static and
> 	add fold_arbitrary_n parameter.  Generalize the arbitrary-pointer
> 	fold to supported constant lengths when requested.
> 	(gimple_fold_builtin): Pass false to gimple_fold_builtin_memset.
> 	* gimple-fold.h (gimple_fold_builtin_memset): Declare.
> 	* tree-call-cdce.cc (shrink_wrap_len_call): Request the multi-byte
> 	arbitrary-pointer memset fold after pinning the guarded length.
>
> gcc/testsuite/ChangeLog:
>
> 	PR tree-optimization/102202
> 	* gcc.dg/pr102202-fold-zero-n.c: New test.
>
> Signed-off-by: Naveen <[email protected]>
>
> @@ -1481,12 +1484,18 @@ gimple_fold_builtin_memset (gimple_stmt_iterator *gsi, tree c, tree len)
>
>       {
> -      /* Keep the original call until object-size analysis has inspected it.  */
> +      /* Keep the arbitrary-pointer fold until object-size analysis has
> +	 inspected the original call.  Preserve the old early ADDR_EXPR fold
> +	 for multi-byte memsets.  */
>         if (!(cfun->curr_properties & PROP_objsz))
> -	return false;
> +	{
> +	  if (length == 1)
> +	    return false;
> +	  goto normal_memset;
> +	}
So it seems like cdce is always run after PROP_objsz is set, at least 
from a cursory scan of passes.def.   So it would seem this code is 
dead.  I feel like I must be missing something.


I don't see anything particularly concerning.  Not a fan of the goto, 
but I can see why you used it.  The alternative would be to take 
everything from teh goto and beyond and factor that into its own routine 
and call it at the appropriate places.

I'm inclined to ACK, but would like to understand if we really need that 
fragment with the PROP_objsize check anymore.

Jeff
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.