From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id CE2253858D32 for ; Thu, 10 Aug 2023 22:16:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CE2253858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="6.01,163,1684828800"; d="scan'208";a="15842811" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 10 Aug 2023 14:16:38 -0800 IronPort-SDR: m2DwPLWN1+h6/5fQ/FZYeJzYXHFcL/C+Jo/zzGisr3+axpbgFx6tXmRdnlTw/H8qES4rxPWWKE efS0N6Xjffuub5tx/jL9kmyWShL6WDojhmIBfbzn80Fmn2Ox8jLQhxpCDfA7Vj5rRr5jks/C7l iL6QVjYu+6rZezaa64m13svMXacwm/qYeHbmNBPlkgp26TKUVaU1zKZ+FxwpyydnEbSwF2TsHf tbRe2tsa7+wXJEB2mqgGUGwcthrg5IgPKP/RQb5tRHz17Chpw2SZ4/afkmyonV3sGTthILWBi5 gUk= Date: Thu, 10 Aug 2023 22:16:33 +0000 From: Joseph Myers To: Richard Biener CC: Phoebe Wang , "Wang, Phoebe" , Hongtao Liu , "Jiang, Haochen" , "gcc-patches@gcc.gnu.org" , "ubizjak@gmail.com" , "Liu, Hongtao" , "Zhang, Annita" , x86-64-abi , llvm-dev , Craig Topper Subject: Re: Intel AVX10.1 Compiler Design and Support In-Reply-To: Message-ID: References: <20230808071312.1569559-1-haochen.jiang@intel.com> <8fb470de-d2a3-3e71-be6a-ccc7f4f31a31@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3104.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 10 Aug 2023, Richard Biener via Gcc-patches wrote: > Isn't this situation similar to the not defined ABI when passing generic > vectors (via __attribute__((vector_size))) that do not map to vectors supported > by the current ISA? There's cases like vector<2> char or vector<1> double > to consider for example that would fit in a lowpart of a supported vector > register and as in the AVX512 case vectors that are larger than any supported > vector register. Note there is a difference in some cases (I don't know if this is relevant for x86) between "vectors supported by the current ISA" and "vectors whose ABI, for ISAs that do support them, can be implemented using the current ISA". Specifically, when working on the VFP AAPCS variant for 32-bit Arm, I made sure that generic vectors had the same ABI on all processors supporting VFP, whether or not the vector parts of the instruction set were supported on the chosen processor. On 32-bit Arm that's possible because vector registers are the same as floating-point registers (and even the single-precision-only VFP variant has suitable load and store instructions). Of course if your ABI for some kinds of vectors uses registers not supported on all processors, and on the processors that do support those registers you use that ABI for corresponding generic vectors, then you won't be able to be compatible with that ABI for those generic vectors on processors without those registers. -- Joseph S. Myers joseph@codesourcery.com