From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9E4043858D32 for ; Thu, 10 Aug 2023 16:00:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E4043858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691683259; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=U4m793QqiR4At2moE9QDHUhSMato36Thqk2paQTLAfE=; b=YZ1Kg5Q3XFvUu4aXrCWyXKZaokcb+Oy/P2Zw52CcUvn9d5+Oh9oDk6RLg+9u9uOKuOsPR3 63OuVPXGB5qG6FMNEiGyj+p/h8gsj23DwNDctYWw1k3aHa1Iqt1L2QwyfhLIimGn6CUirr D/vwkHMOMkUtMvpFn0Y9ifM7nqsz8tM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-659-bxSa0VsqNfeZBPpSi1VmFw-1; Thu, 10 Aug 2023 12:00:54 -0400 X-MC-Unique: bxSa0VsqNfeZBPpSi1VmFw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4156D817077; Thu, 10 Aug 2023 16:00:52 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.169]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E388F1121318; Thu, 10 Aug 2023 16:00:51 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 37AG0mn22356981 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 10 Aug 2023 18:00:49 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 37AG0lBg2356980; Thu, 10 Aug 2023 18:00:47 +0200 Date: Thu, 10 Aug 2023 18:00:46 +0200 From: Jakub Jelinek To: "Jiang, Haochen" Cc: "gcc-patches@gcc.gnu.org" , "ubizjak@gmail.com" , "Liu, Hongtao" , "Beulich, Jan" , Richard Biener , Joseph Myers , Phoebe Wang Subject: Re: Intel AVX10.1 Compiler Design and Support Message-ID: Reply-To: Jakub Jelinek References: <20230808071312.1569559-1-haochen.jiang@intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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: On Thu, Aug 10, 2023 at 03:08:31PM +0000, Jiang, Haochen via Gcc-patches wrote: > There are lots of discussions on arch level and ABIs and I really appreciate that. > > For the arch level issue, it might be a little early to discuss and should not block > these patches. > > For ABI issue, the problem actually comes from the current behavior between > GCC and clang/LLVM are different in return value for m512 w/o 512 bit support. > Then it becomes a question to get unified and we get the whole discussion. > However, it is a corner case. What LLVM does looks just wrong to me. Try: typedef int V256 __attribute__((vector_size (32))); typedef int V512 __attribute__((vector_size (64))); typedef int V1024 __attribute__((vector_size (128))); V256 foo256 (V256 x, V256 y) { return x + y; } V512 foo512 (V512 x, V512 y) { return x + y; } V1024 foo1024 (V1024 x, V1024 y) { return x + y; } with -msse4, -mavx2 and -mavx512f. GCC passes all arguments and all return values in memory with warnings for the first case, all but foo256 in the second case and everything in foo1024 in the last case. That matches the psABI without/with __m256 and/or __m512 additions, it is unfortunate that there is no interoperability between the pre-AVX2 vs. AVX2+ resp. pre-AVX512F vs. AVX512F+ passing/returning, but that is a consequence of wanting to get fast code on new ISAs. While LLVM passes all the arguments the same as GCC (though without warnings), but for foo256 returns the result in xmm0/xmm1 pair with -msse4 and in ymm0 for -mavx2 and later, for foo512 returns the result in xmm0/xmm1/xmm2/xmm3 quadruplet for -msse4, in ymm0/ymm1 pair for -mavx2 and finally in zmm0 for -mavx512f. And for foo1024 in memory for -msse4, in ymm0/ymm1/ymm2/ymm3 quadruplet for -mavx2 and in zmm0/zmm1 pair for -mavx512f. I have no idea what in psABI would that be based on, both the different passing of arguments vs. returning of result, but more importantly, this doesn't mean 2 different ABIs for one function depending on ISA flags, but 3, maybe 4 (with -mno-sse?). Jakub