From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.zhaoxin.com (mx2.zhaoxin.com [203.110.167.99]) by sourceware.org (Postfix) with ESMTPS id 01045382A2EB for ; Thu, 27 Oct 2022 09:09:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 01045382A2EB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=zhaoxin.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zhaoxin.com X-ASG-Debug-ID: 1666861741-1eb14e7e6354db0001-Gfy7bY Received: from ZXSHMBX3.zhaoxin.com (ZXSHMBX3.zhaoxin.com [10.28.252.165]) by mx2.zhaoxin.com with ESMTP id yrjj6sEEj1kRPxQa (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 27 Oct 2022 17:09:01 +0800 (CST) X-Barracuda-Envelope-From: Mayshao-oc@zhaoxin.com X-Barracuda-RBL-Trusted-Forwarder: 10.28.252.165 Received: from zxbjmbx1.zhaoxin.com (10.29.252.163) by ZXSHMBX3.zhaoxin.com (10.28.252.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Thu, 27 Oct 2022 17:09:01 +0800 Received: from ZXBJMBX02.zhaoxin.com (10.29.252.6) by zxbjmbx1.zhaoxin.com (10.29.252.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Thu, 27 Oct 2022 17:09:00 +0800 X-Barracuda-RBL-Trusted-Forwarder: 10.28.252.165 Received: from ZXBJMBX02.zhaoxin.com ([fe80::5060:9880:fd25:4269]) by ZXBJMBX02.zhaoxin.com ([fe80::5060:9880:fd25:4269%8]) with mapi id 15.01.2507.012; Thu, 27 Oct 2022 17:09:00 +0800 X-Barracuda-RBL-Trusted-Forwarder: 10.29.252.163 From: Mayshao-oc To: =?iso-8859-15?Q?Martin_Li=A8ka?= , Uros Bizjak CC: "Silvia Zhao(BJ-RD)" , TimHu-oc , "Cobe Chen(BJ-RD)" , "gcc-patches@gcc.gnu.org" , "Hawk Wang(BJ-RD)" , "Louis Qi(BJ-RD)" , Jan Hubicka Subject: Re: [PATCH] [x86_64] Zhaoxin lujiazui enablement Thread-Topic: [PATCH] [x86_64] Zhaoxin lujiazui enablement X-ASG-Orig-Subj: Re: [PATCH] [x86_64] Zhaoxin lujiazui enablement Thread-Index: AQHYQbswgJJ4PmPdVEiVELjIJh7fJazUZHdpgUrpJgCAAlzQDv//nIYAgAH5jlY= Date: Thu, 27 Oct 2022 09:09:00 +0000 Message-ID: <71e45f1a072a400c8d6a92ead303bab4@zhaoxin.com> References: <20220325020815.16674-1-MayShao-oc@zhaoxin.com> <9263704e-b2f1-f21d-f888-a884547a0cf5@suse.cz> <28ad8b4bd1ab4c7997c3f6d6b694895f@zhaoxin.com>,<76a79f24-dcff-a692-f782-956305090ba5@suse.cz> In-Reply-To: <76a79f24-dcff-a692-f782-956305090ba5@suse.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.29.8.5] Content-Type: multipart/alternative; boundary="_000_71e45f1a072a400c8d6a92ead303bab4zhaoxincom_" MIME-Version: 1.0 X-Barracuda-Connect: ZXSHMBX3.zhaoxin.com[10.28.252.165] X-Barracuda-Start-Time: 1666861741 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.28.252.36:4443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at zhaoxin.com X-Barracuda-Scan-Msg-Size: 6724 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.101711 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 HTML_MESSAGE BODY: HTML included in message X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,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: --_000_71e45f1a072a400c8d6a92ead303bab4zhaoxincom_ Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable >> >> Hi Martin: >> Thanks for your patch, I comment the questions below. >Hi. >:) >> >>> Hello. >> >>> I noticed this patch set which is kind of related to https://gcc.gnu.or= g/bugzilla/show_bug.cgi?id=3D107364. >> >>> And I have a couple of questions: >> >>>1) I noticed you drop AVX and F16C features for the newly added "lujiazu= i". Why do you need it? >>> I would expect these features would be properly detected by cpuid? >> >> Yes, these features could be detected by cpuid, and in respect of functi= onality, these features are ok, but in respect of performance, these featur= es need further improvement, so we decide to drop it now, and add these fea= tures back when performance meet our expectation. > I see. So theoretically you can increase costs of the corresponding insns= and that could be dropped now? > But I'm not a costing expert. I am new to gcc, and have lots of things to learn. About LTO and PGO, I hav= e read some knowledge you and hubicka shared, and it helps me a lot, As a p= erformance issue, it is a good idea to use cost model to solve, and disable= avx entirely seems overkill. But cost model need to set the appropriate va= lue of the cost, it's challenging to specify the number and more challengin= g to justify why we set that number. Our current approach have a pitfall to= accommodate AVX intrinsic functions(eg: __mm256_loadu_pd), we could use -m= avx to specify this explictly to overcome this. >> >>> 2) If you really need it, can you please test for me the attached patch= ? It should come up >>> with a new function. >> >> I have tested the patch, It's ok. > Good, I'm going to install it. >> >>> 3) Have question about: >> >>> else if (vendor =3D=3D signature_CENTAUR_ebx && family < 0x07) >>> cpu_model->__cpu_vendor =3D VENDOR_CENTAUR; >>> else if (vendor =3D=3D signature_SHANGHAI_ebx >>> || vendor =3D=3D signature_CENTAUR_ebx) >> >>> Are there any signature_CENTAUR_ebx models with family =3D=3D 0x7 ? >>> Similarly, are there any signature_SHANGHAI_ebx modes with family < 0x7= ? >> >> Yes, both cases exist in our products. > Good. Then we miss a CPU features detection for (vendor =3D=3D signature_= CENTAUR_ebx && family < 0x07) > aka https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107364. But it's not w= orth it as it's a legacy hardware, > right? Yes, for legacy hardware, we need to keep it work correctly, but in respect= of performance, we don't spend a lot of time to tune. > Cheers, > Martin >> >>> Thanks, >> Martin >> >> BR >> Mayshao --_000_71e45f1a072a400c8d6a92ead303bab4zhaoxincom_--