On Wed, Aug 9, 2023 at 8:37 AM Liu, Hongtao <hongtao....@intel.com> wrote: > > > > > -----Original Message----- > > From: Uros Bizjak <ubiz...@gmail.com> > > Sent: Wednesday, August 9, 2023 2:33 PM > > To: Liu, Hongtao <hongtao....@intel.com> > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [PATCH V2] [X86] Workaround possible CPUID bug in Sandy > > Bridge. > > > > On Wed, Aug 9, 2023 at 3:48 AM liuhongt <hongtao....@intel.com> wrote: > > > > > > > Please rather do it in a more self-descriptive way, as proposed in > > > > the attached patch. You won't need a comment then. > > > > > > > > > > Adjusted in V2 patch. > > > > > > Don't access leaf 7 subleaf 1 unless subleaf 0 says it is supported > > > via EAX. > > > > > > Intel documentation says invalid subleaves return 0. We had been > > > relying on that behavior instead of checking the max sublef number. > > > > > > It appears that some Sandy Bridge CPUs return at least the subleaf 0 > > > EDX value for subleaf 1. Best guess is that this is a bug in a > > > microcode patch since all of the bits we're seeing set in EDX were > > > introduced after Sandy Bridge was originally released. > > > > > > This is causing avxvnniint16 to be incorrectly enabled with > > > -march=native on these CPUs. > > > > > > gcc/ChangeLog: > > > > > > * common/config/i386/cpuinfo.h (get_available_features): Check > > > EAX for valid subleaf before use CPUID. > > > --- > > > gcc/common/config/i386/cpuinfo.h | 82 > > > +++++++++++++++++--------------- > > > 1 file changed, 43 insertions(+), 39 deletions(-) > > > > > > diff --git a/gcc/common/config/i386/cpuinfo.h > > > b/gcc/common/config/i386/cpuinfo.h > > > index 30ef0d334ca..9fa4dec2a7e 100644 > > > --- a/gcc/common/config/i386/cpuinfo.h > > > +++ b/gcc/common/config/i386/cpuinfo.h > > > @@ -663,6 +663,7 @@ get_available_features (struct __processor_model > > *cpu_model, > > > unsigned int max_cpuid_level = cpu_model2->__cpu_max_level; > > > unsigned int eax, ebx; > > > unsigned int ext_level; > > > + unsigned int subleaf_level; > > > > Oh, I failed this in my previous review. This variable should be named > > max_subleaf_level, as it represents the maximum supported ECX value. > I've committed previous patch ,but not backport yet. > Guess I can just commit another patch to change the name? > For backport, I'll merge the change together with just 1 commit.
Yes. It is a trivial minor change. Uros.
