> -----Original Message-----
> From: H.J. Lu <[email protected]>
> Sent: Wednesday, June 24, 2026 8:46 AM
> To: GCC Patches <[email protected]>; Uros Bizjak
> <[email protected]>; Liu, Hongtao <[email protected]>
> Subject: [PATCH] x86-64: Expand bounded memset and memcpy like
> memmove
>
> commit 401199377c50045ede560daf3f6e8b51749c2a87
> Author: H.J. Lu <[email protected]>
> Date: Tue Jun 17 10:17:17 2025 +0800
>
> x86: Improve vector_loop/unrolled_loop for memset/memcpy
>
> uses move_by_pieces and store_by_pieces for memcpy and memset epilogues
> with the fixed epilogue size. Since move_by_pieces and store_by_pieces don't
> use the maximum size info, they generate extra branches and moves for
> bounded memcpy and memset. Commit
>
> commit b41f96465190751561f6909e858604ceab00595b
> Author: H.J. Lu <[email protected]>
> Date: Mon Oct 20 16:14:34 2025 +0800
>
> x86-64: Inline memmove with overlapping unaligned loads and stores.
>
> inlines memmove with overlapping unaligned and stores which reduces the
> numbers of branches as well as moves when the maximum size is known.
> Rename ix86_expand_movmem to ix86_expand_set_or_movmem and extend
> it to inline bounded memcpy and memset. Update
> ix86_expand_set_or_cpymem to call ix86_expand_set_or_movmem for
> TARGET_INLINE_SET_OR_CPYMEM_LIKE_MOVMEM.
>
> In addition to reduce 727.cppcheck_r O2 code size by ~9%, there're another
> ~8 benchmarks whose code sizes are reduced >2% across spec2026 and
> spec2017 with march=x86-64-v3 O2, no big code size impact for Ofast,
> performance impact is negligible(slightly better, but all under noise
> range) for both O2 and Ofast.
>
> gcc/
>
> PR target/125856
> PR target/125865
> * config/i386/i386-expand.cc (promote_duplicated_reg): Also duplicate non-
> const0_rtx and non-constm1_rtx integer constants to integer vector.
> (ix86_expand_set_or_cpymem): Call ix86_expand_unroll_movmem for
> TARGET_INLINE_SET_OR_CPYMEM_LIKE_MOVMEM.
it says ix86_expand_set_or_cpymem calls ix86_expand_unroll_movmem, but the
patch actually calls ix86_expand_set_or_movmem. It also mentions a
promote_duplicated_reg change that is not in this patch.
>+/* Return a value rtx in MODE for memset from MEMSET_VALS. */
the comment block has an odd blank line before */.
>+
>+static rtx
>+ix86_expand_memset_val (rtx *memset_vals, machine_mode mode)
>+{
>+ rtx val;
>+ if (mode == QImode)
>+ val = memset_vals[memset_val_byte];
>+ else if (mode == word_mode)
>+ val = memset_vals[memset_val_word];
>+ else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
>+ {
>+ if (GET_MODE (memset_vals[memset_val_vector]) == mode)
>+ val = memset_vals[memset_val_vector];
>+ else
>+ {
>+ machine_mode vmode = GET_MODE (memset_vals[memset_val_vector]);
>+ if (memset_vals[memset_val_vector] == CONST0_RTX (vmode))
The if under machine_mode vmode = ... is misindented,
>+/* X86_TUNE_INLINE_SET_OR_CPYMEM_LIKE_MOVMEM: Enable inlining bounded
>+ memset and memcpy like memmove with overlapping unaligned moves. This
>+ requires target to handle misaligned moves and partial memory stalls
>+ reasonably well. */
>+DEF_TUNE (X86_TUNE_INLINE_SET_OR_CPYMEM_LIKE_MOVMEM,
>+ "inline_set_or_cpymem_like_movmem",
>+ m_386 | m_486 | m_CORE_ALL | m_AMD_MULTIPLE | m_ZHAOXIN | m_TREMONT
>+ | m_CORE_HYBRID | m_CORE_ATOM | m_C86_4G | m_GENERIC)
Do we need a separate tune knob for this? The enable mask matches
X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES, and the expander already
restricts this to x86-64, non-size-optimized, bounded cases. Unless we have
data showing different CPU behavior from the existing misaligned-move-string-op
tuning, I’d prefer reusing the existing tune or enabling this directly under
the existing guards.
Please add at least one runtime testcase for the boundary sizes. The asm scans
are useful for code shape, but this patch changes overlapping first/last stores
and loop tails for variable bounded sizes. I’d want dg-do run coverage around
0,1,2,3,4,7,8,15,16,31,32,63,64,127,128,... for both memcpy and memset.
