From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by sourceware.org (Postfix) with ESMTPS id 45BA13858D33 for ; Tue, 8 Aug 2023 07:58:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 45BA13858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691481485; x=1723017485; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=PDbJ/AxlX5JK5W0SoU+5lEfre+TL6otxAQhF1DYP4MY=; b=mYMtRF/yLUyEf423RfvKMu4isKo4ynpoxOlDUNCrrFq1DX2gr5xsQ+ZN QrwaA4a7EfvXTtS4EZdOesYd6XCTpg//VLOn4NWSGDA+gsnwRciuyRfdA kkuv8hE8eYgBBQajL1BQuVILo0DeX/Ny1xpt/LluiJ2uOsgYiznaJk+7q BZwTWx3SSAkfCEaNHa39H94sPsstsINj8xXFRy5oQ4nlfGai4yF/B5XqQ 4LQmP7MVgpLMsCiSg3fVw/OzGXDHDnNY83HKqTiZldYfuv+0cR5IA4l5p aGaEgfk6AZYjebRU3avJOC9xymgTsNQUr/AFDrd9wxKLcWJw4I6+D68y1 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="434599805" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="434599805" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2023 00:58:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="845363432" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="845363432" Received: from shvmail03.sh.intel.com ([10.239.245.20]) by fmsmga002.fm.intel.com with ESMTP; 08 Aug 2023 00:58:01 -0700 Received: from shliclel4217.sh.intel.com (shliclel4217.sh.intel.com [10.239.240.127]) by shvmail03.sh.intel.com (Postfix) with ESMTP id D4B5C1005604; Tue, 8 Aug 2023 15:58:00 +0800 (CST) From: liuhongt To: gcc-patches@gcc.gnu.org Cc: ubizjak@gmail.com, phoebe.wang@intel.com, craig.topper@gmail.com Subject: [PATCH] [X86] Workaround possible CPUID bug in Sandy Bridge. Date: Tue, 8 Aug 2023 15:56:00 +0800 Message-Id: <20230808075600.1878105-1-hongtao.liu@intel.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. BTW: Thanks for reminder from llvm forks Phoebe and Craig. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk and backport? gcc/ChangeLog: * common/config/i386/cpuinfo.h (get_available_features): Check EAX for valid subleaf before use CPUID. --- gcc/common/config/i386/cpuinfo.h | 84 +++++++++++++++++--------------- 1 file changed, 46 insertions(+), 38 deletions(-) diff --git a/gcc/common/config/i386/cpuinfo.h b/gcc/common/config/i386/cpuinfo.h index 30ef0d334ca..24ab2252eb0 100644 --- a/gcc/common/config/i386/cpuinfo.h +++ b/gcc/common/config/i386/cpuinfo.h @@ -874,45 +874,53 @@ get_available_features (struct __processor_model *cpu_model, set_feature (FEATURE_AVX512FP16); } - __cpuid_count (7, 1, eax, ebx, ecx, edx); - if (eax & bit_HRESET) - set_feature (FEATURE_HRESET); - if (eax & bit_CMPCCXADD) - set_feature(FEATURE_CMPCCXADD); - if (edx & bit_PREFETCHI) - set_feature (FEATURE_PREFETCHI); - if (eax & bit_RAOINT) - set_feature (FEATURE_RAOINT); - if (avx_usable) - { - if (eax & bit_AVXVNNI) - set_feature (FEATURE_AVXVNNI); - if (eax & bit_AVXIFMA) - set_feature (FEATURE_AVXIFMA); - if (edx & bit_AVXVNNIINT8) - set_feature (FEATURE_AVXVNNIINT8); - if (edx & bit_AVXNECONVERT) - set_feature (FEATURE_AVXNECONVERT); - if (edx & bit_AVXVNNIINT16) - set_feature (FEATURE_AVXVNNIINT16); - if (eax & bit_SM3) - set_feature (FEATURE_SM3); - if (eax & bit_SHA512) - set_feature (FEATURE_SHA512); - if (eax & bit_SM4) - set_feature (FEATURE_SM4); - } - if (avx512_usable) - { - if (eax & bit_AVX512BF16) - set_feature (FEATURE_AVX512BF16); - } - if (amx_usable) + /* According to document, when subleaf is invliad, EAX,EBX,ECX,EDX should + return 0 for CPUID (7, 1, EAX, EBX, ECX, EDX). + But looks like it doesn't satisfy the document on some CPU, refer to + https://reviews.llvm.org/D155145. + Manually check valid subleaf here. */ + if (eax) { - if (eax & bit_AMX_FP16) - set_feature (FEATURE_AMX_FP16); - if (edx & bit_AMX_COMPLEX) - set_feature (FEATURE_AMX_COMPLEX); + __cpuid_count (7, 1, eax, ebx, ecx, edx); + if (eax & bit_HRESET) + set_feature (FEATURE_HRESET); + if (eax & bit_CMPCCXADD) + set_feature(FEATURE_CMPCCXADD); + if (edx & bit_PREFETCHI) + set_feature (FEATURE_PREFETCHI); + if (eax & bit_RAOINT) + set_feature (FEATURE_RAOINT); + if (avx_usable) + { + if (eax & bit_AVXVNNI) + set_feature (FEATURE_AVXVNNI); + if (eax & bit_AVXIFMA) + set_feature (FEATURE_AVXIFMA); + if (edx & bit_AVXVNNIINT8) + set_feature (FEATURE_AVXVNNIINT8); + if (edx & bit_AVXNECONVERT) + set_feature (FEATURE_AVXNECONVERT); + if (edx & bit_AVXVNNIINT16) + set_feature (FEATURE_AVXVNNIINT16); + if (eax & bit_SM3) + set_feature (FEATURE_SM3); + if (eax & bit_SHA512) + set_feature (FEATURE_SHA512); + if (eax & bit_SM4) + set_feature (FEATURE_SM4); + } + if (avx512_usable) + { + if (eax & bit_AVX512BF16) + set_feature (FEATURE_AVX512BF16); + } + if (amx_usable) + { + if (eax & bit_AMX_FP16) + set_feature (FEATURE_AMX_FP16); + if (edx & bit_AMX_COMPLEX) + set_feature (FEATURE_AMX_COMPLEX); + } } } -- 2.31.1