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 EFA033858296 for ; Fri, 10 Mar 2023 08:37:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EFA033858296 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=1678437439; 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=4ERJ4TW5jSEej0Vg2xnwxoiKbXpFmWlyC/EB32sc6nA=; b=J2q6+0XLA2cu/Pz/m9vFLqMsHy5VUTiaL72palYpUSonf1zSoMRBEAK5siqQTddLsw//bS cScnUdOh3R/itLvPMJdH81T1ese9zZipRuM8vSd2Ru2D81Qahcrazx9gx9NtpLANHLyc6z wr6oDNGH5F0sOd52FdRND4M9PftowFA= 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-493-7LKeIsrNPgGX_o1oh55MGg-1; Fri, 10 Mar 2023 03:37:13 -0500 X-MC-Unique: 7LKeIsrNPgGX_o1oh55MGg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 426F4885623; Fri, 10 Mar 2023 08:37:13 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 021EF2166B26; Fri, 10 Mar 2023 08:37:12 +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 32A8bAQi844427 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 10 Mar 2023 09:37:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 32A8b94N844424; Fri, 10 Mar 2023 09:37:09 +0100 Date: Fri, 10 Mar 2023 09:37:09 +0100 From: Jakub Jelinek To: Richard Earnshaw , Kyrylo Tkachov , richard.sandiford@arm.com, Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: Re: AArch64 bfloat16 mangling Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 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_H2,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, Mar 09, 2023 at 05:14:11PM +0000, Richard Sandiford wrote: > We decided to keep the current mangling of __bf16 and use it for > std::bfloat16_t too. __bf16 will become a non-standard arithmetic type. > This will be an explicit diversion from the Itanium ABI. > > I think that's equivalent to your (2) without the part about following > the Itanium ABI. I'm afraid I have no idea how can the above work though. Diversion from the Itanium ABI is doable, we have various examples where we mangle things differently, say on powerpc* where long double is mangled as g if it is IBM double double format (i.e. Itanium __float128) while for long double the spec says e, and as u9__ieee128 if it is IEEE quad. __float128 also mangles as u9__ieee128 and so does __ieee128. The problem is if __bf16 needs to be treated differently from decltype (0.0bf16) aka std::bfloat16_t (the former being a non-standard arithmetic type, the latter being C++23 extended floating-point type, then they need to be distinct types. And distinct types need to mangle differently. Consider #include template void bar () {} void baz () { bar<__bf16> (); bar (); bar (); } If __bf16 is distinct from the latter two which are the same type, then it will instantiate bar twice, for both of those types, but if they are mangled the same, will emit two functions with the same name and assembler will reject it (or LTO might ICE etc.). Note, e.g. void foo (__float128, __ieee128, long double, _Float128) {} template void bar () {} void baz () { bar <__float128> (); bar <__ieee128> (); bar (); } works on powerpc64le-linux with -mlong-double-128 -mabi=ieeelongdouble because __float128, __ieee128 and long double types are in that case the same type, not distinct, so e.g. bar is instantiated just once (only _Float128 mangles differently above). With -mlong-double-128 -mabi=ibmlongdouble __float128 and __ieee128 are the same (non-standard) type, while long double mangles differently (g) and _Float128 too, so bar is instantiated twice. So, either __bf16 should be also extended floating-point type like decltype (0.0bf16) and std::bfloat16_t and in that case it is fine if it mangles u6__bf16, or __bf16 will be a distinct type from the latter two, __bf16 non-standard arithmetic type while the latter two extended floating-point types, but then they need to mangle differently, most likely u6__bf16 vs. DF16b. Jakub