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