On Sun, Sep 28, 2025 at 9:08 AM Hongtao Liu <[email protected]> wrote: > > On Sun, Sep 28, 2025 at 8:32 AM H.J. Lu <[email protected]> wrote: > > > > On Sun, Sep 28, 2025 at 8:18 AM Liu, Hongtao <[email protected]> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: H.J. Lu <[email protected]> > > > > Sent: Sunday, September 28, 2025 6:33 AM > > > > To: Liu, Hongtao <[email protected]> > > > > Cc: [email protected] > > > > Subject: Re: [PATCH] Deprecate -mmove-max= and related tuning. > > > > > > > > On Fri, Sep 26, 2025 at 9:40 AM liuhongt <[email protected]> wrote: > > > > > > > > > > For memset, the size of used vector is decided by MIN(MOVE_MAX_PIECES, > > > > > STORE_MAX_PIECES). > > > > > Unless there's u-arch prefer big size vector for memcpy and small size > > > > > vector for memset, there's no need to have a separate option or tune > > > > > for it. > > > > > In general, x86 backend always prefer big size vector for memset due > > > > > to STLF issue. > > > > > So for maintaince convenience, the patch remove store_max related tune > > > > > and marked the mstore-max as deprecated. > > > > > > > > > > Bootstrapped and regtested on x86_64-pc-linux{-m32,}. > > > > > H.J Any comments? > > > > > > > > Does it change -mstore-max or -mmove-max? The subject says -mmove-max, > > > > but the commit message says -mstore-max. > > > > > > Typo, The patch only changes -mstore-max > > > 1. It removes tune of {AVX256,AVX512}_STORE_BY_PIECES. > > > 2. Deprecate mstore-max by aliasing it to -mmove-max and issues a warning. > > > > Does the patch include tests for -mmove-max aliasing and the warning > > message? > No, do we need it? It seems simple enough.
Any change should have tests to verify that it is done correctly. -- H.J.
