On Thu, Aug 13, 2026 at 8:20 PM Jeffrey Law <[email protected]> wrote: > > > > 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 don't like adding side-entries into fold_stmt here, memset (p, x, CST) should generally be expanded inline, not only when coming from the cddce path. IIRC we've argued this before with moderate success, mostly circling around perceived fallout in some testcases with respect to late warnings. > I'm inclined to ACK, but would like to understand if we really need that > fragment with the PROP_objsize check anymore. > > Jeff
