On Mon, Jun 22, 2026 at 1:26 PM Kewen Lin <[email protected]> wrote:
>
> Hi Uros,
>
> 在 2026/6/16 16:52, Kewen Lin 写道:
> > Hi Uros,
> >
> > 在 2026/6/16 15:40, Uros Bizjak 写道:
> >> On Tue, Jun 16, 2026 at 4:49 AM Kewen Lin <[email protected]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Authored-by: Xin Liu <[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,
> >>> builtin 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 scheduling reservations 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.  This patch
> >>> does not affect genautomata build time.
> >>>
> >>> Bootstrapped and regtested on a hygon c86-4g-m7 machine, as well as
> >>> a cfarm x86-64 machine.
> >>>
> >>> Is it ok for trunk?  Also ok to backport to gcc-16/gcc-15 after burn-in
> >>> time?
> >>
> >> OK with some minor inconsistencies resolved (see inline), also OK for
> >> backports after some time in mainline.
> >>
> >> Thanks,
> >> Uros.
> >>
> >>>
> [snip ....]>>> diff --git a/gcc/common/config/i386/cpuinfo.h 
> b/gcc/common/config/i386/cpuinfo.h
> >>> index 62e9210b067..f59090c8cde 100644
> >>> --- a/gcc/common/config/i386/cpuinfo.h
> >>> +++ b/gcc/common/config/i386/cpuinfo.h
> >>> @@ -383,6 +383,12 @@ get_hygon_cpu (struct __processor_model *cpu_model,
> >>>           CHECK___builtin_cpu_is ("c86-4g-m7");
> >>>           cpu_model->__cpu_subtype = HYGONFAM18H_C86_4G_M7;
> >>>         }
> >>> +      else if (model == 0x8)
> >>
> >> This condition is inconsistent with the condition in driver-i386.cc, where
> >>
> >> else if (model >= 8) // open-ended
> >>    processor = PROCESSOR_C86_4G_M8;
> >>
> >> I think this should be (model >= 0x8) so a hypothetical model 9 would
> >> get m8 tuning.
> >
> > As the else if hunk has a CHECK for exact m8, it was intentional to keep
> > the checking for "== 8" only.  Does it sound reasonable?
> >
>
> With the above explanation, do you still prefer to keep the consistency with
> driver-i386.cc, or agree it's fine to leave them incosistent?

The function will return cpu = NULL for an unknown CPU, so I guess it
is OK as proposed in the patch.

Thanks,
Uros.

Reply via email to