On Mon, Jun 1, 2026 at 5:02 AM Hongtao Liu <[email protected]> wrote: > > On Fri, May 29, 2026 at 5:13 PM Uros Bizjak <[email protected]> wrote: > > > > On Fri, May 29, 2026 at 10:37 AM Hongyu Wang <[email protected]> wrote: > > > > > > Thanks for noting this, the soft-enable way looks more reasonable. > > > Attached patch using preferred_for_speed with bootstrapping && regtest. > Ok for the trunk.
I wonder what the issue is with memory NDD form, I'd have expected that to reduce the load on the frontend and I-cache while being split into load(/store?) and operation uops, thus behave identical to the backend apart from allowing more register renaming freedom? Richard. > > > > > Yes, this is now using the correct (modern) infrastructure: > > > > --q-- > > The ‘enabled’ attribute is a correctness property. It tells GCC to act > > as though the disabled alternatives were never defined in the first > > place. This is useful when adding new instructions to an existing > > pattern in cases where the new instructions are only available for > > certain cpu architecture levels (typically mapped to the ‘-march=’ > > command-line option). > > > > In contrast, the ‘preferred_for_size’ and ‘preferred_for_speed’ > > attributes are strong optimization hints rather than correctness > > properties. ‘preferred_for_size’ tells GCC which alternatives to > > consider when adding or modifying an instruction that GCC wants to > > optimize for size. ‘preferred_for_speed’ does the same thing for speed. > > Note that things like code motion can lead to cases where code optimized > > for size uses alternatives that are not preferred for size, and > > similarly for speed. > > --/q-- > > > > Acked-by: Uros Bizjak <[email protected]> > > > > (I will leave final approval to Hongtao). > > > > Uros. > > > > -- > BR, > Hongtao
