Hi Uros, 在 2026/6/13 18:41, Uros Bizjak 写道: > On Sat, Jun 13, 2026 at 8:20 AM Kewen Lin <[email protected]> wrote: >> >> Hi, >> >> This patch is for c86-4g-m8 support and from [email protected]. >> >> Add c86-4g-m8 as a new HYGON Family 18h model 8 processor. It >> inherits the c86-4g-m7 ISA set and most tuning decisions, including >> the same processor costs and scheduling model baseline. >> >> The patch wires c86-4g-m8 into the common x86 processor tables, >> driver CPU detection, target macros, --with-arch/--with-cpu handling, >> built-in CPU detection and documentation. It also extends the c86-4g >> tuning masks that already special-case c86-4g-m7 to cover c86-4g-m8. >> >> For scheduling, rename the shared scheduling description file from >> gcc/config/i386/c86-4g-m7.md to gcc/config/i386/c86-4g-m7m8.md >> and reuse the c86-4g-m7 model for c86-4g-m8 where the latency and >> resource usage are the same. Add separate c86-4g-m8 reservations for >> the few operations with different latency. While extending the model, >> also fix some existing unit modeling mistakes in the shared >> reservations and rename several instruction templates so their names >> better match the instructions they cover. Note that as tested this >> patch does not affect genautomata build time. > > Please don't mix new developments with fixes. If possible, please > split fixes out of the main patch to first fix what is already in the > repository and then extend the fixed source with new functionality. > Fixes have different review "weight" than new additions.
Thanks for the review and suggestion! Indeed, splitting it is better! As suggested, two patches were just posted as: i386: Fix some c86-4g-m7 reservations https://gcc.gnu.org/pipermail/gcc-patches/2026-June/720391.html i386: Add HYGON c86-4g-m8 support https://gcc.gnu.org/pipermail/gcc-patches/2026-June/720392.html > >> Bootstrapped and regtested on a hygon c86-4g-m7 machine, as well as >> a cfarm x86-64 machine. > > IMO, mostly mechanical patches like this one are ideal candidates for > AI review to find inadvertent omissions and other inconsistencies. One > is mentioned below. Good idea! > > Other changes outside .md files are OK. > >> Is it ok for trunk? Also ok to backport to gcc-16/gcc-15 (unfrozen) >> after burn-in time? >> >> (define_insn_reservation "c86_4g_m7_avx512_ssecmp_vp_z" 5 >> - (and (eq_attr "cpu" "c86_4g_m7") >> + (and (eq_attr "cpu" "c86_4g_m7,c86_4g_m8") >> (and (eq_attr "type" "ssecmp") >> (and (eq_attr "prefix" "evex") >> (and (eq_attr "mode" "XI") >> (and (eq_attr "c86_attr" "other,ptest") >> (eq_attr "memory" "none")))))) >> - "c86-4g-m7-double,c86-4g-m7-fpu,c86-4g-m7-fpu_1_3") >> + "c86-4g-m7-vector,c86-4g-m7-fpu,c86-4g-m7-fpu_1_3") >> >> (define_insn_reservation "c86_4g_m7_avx512_ssecmp_vp_z_load" 12 >> (and (eq_attr "cpu" "c86_4g_m7") > > The above "c86_4g_m7_avx512_ssecmp_vp_z_load" insn reservation is left > unchanged, missing both changes: addition of c86_4g_m8 handling and > the change to c86-4g-m7-vector. Thanks for catching, hope the new separated ones look better. BR, Kewen
