On Thu, Feb 09, 2023 at 07:30:52AM -0800, H.J. Lu wrote:
> On Thu, Feb 9, 2023 at 4:12 AM Jakub Jelinek <ja...@redhat.com> wrote:
> > get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
> > and just sets stuff up based on CPUID leaf 1, or some extended ones,
> > so I wonder why are we calling it separately for Intel, AMD and Zhaoxin
> > and not for all other CPUs too? I think various programs in the wild
> > which aren't using __builtin_cpu_{is,supports} just check the various CPUID
> > leafs and query bits in there, without blacklisting unknown CPU vendors,
> > so I think even __builtin_cpu_supports ("sse2") etc. should be reliable
> > if those VENDOR_{CENTAUR,CYRIX,NSC,OTHER} CPUs set those bits in CPUID leaf
> > 1 or some extended ones. Calling it for all CPUs also means it can be
> > inlined because there will be just a single caller.
> >
> > I will test on Intel but can't test it on non-Intel (or with some extra
> > effort on AMD; for both of those arches it should be really no change in
> > behavior).
> >
> > Thoughts on this?
>
> No objection here. It just isn't easy to verify CPUID behavior on
> other processors.
Sure, worst case it can be reverted or exceptions could be added if some
CPUs misbehave but then we'd hopefully have detailed into on how exactly it
behaves.
FYI, I've successfully bootstrapped/regtested this on Intel i9-7960X
and Martin Liska has regtested it with just i386.exp tests on AMD.
Uros, is this ok now?
> > 2023-02-09 Jakub Jelinek <ja...@redhat.com>
> >
> > PR target/100758
> > * common/config/i386/cpuinfo.h (get_zhaoxin_cpu): Formatting fixes.
> > (cpu_indicator_init): Call get_available_features for all CPUs with
> > max_level >= 1, rather than just Intel, AMD or Zhaoxin. Formatting
> > fixes.
Jakub
