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 6B9353858D32 for ; Mon, 27 Feb 2023 23:51:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B9353858D32 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=1677541872; 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=CwneSp3/ROvQlpD6dOnQfa15+mp5HaP0HkGt9Z0/gPI=; b=aA1DrZCD07NkSNrVGOaBxlJM9/vGzfXBV7nisn3EsJMGQrB80VTYHcUljrjENIh9R466cr ZJdb5xBv1sX7aZoF1tug3s/BxABL/yRjOs3fcvF54r60DTttOIPlH/zuxj0VOUSJYesRvY KcCH49A+IzoMQKHVA6BL3UOYK6gsIzE= 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-339-mJJMpQX2NmaKYlnGJFufbg-1; Mon, 27 Feb 2023 18:51:09 -0500 X-MC-Unique: mJJMpQX2NmaKYlnGJFufbg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9C37185CBE2 for ; Mon, 27 Feb 2023 23:51:09 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.101]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5D3AE40C6EC4; Mon, 27 Feb 2023 23:51:09 +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 31RNp7Yv3130370 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 28 Feb 2023 00:51:07 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31RNp67d3130369; Tue, 28 Feb 2023 00:51:06 +0100 Date: Tue, 28 Feb 2023 00:51:06 +0100 From: Jakub Jelinek To: Jason Merrill Cc: Jonathan Wakely , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: Add target hook for emit_support_tinfos [PR108883] Message-ID: Reply-To: Jakub Jelinek References: <7163c5db-3025-01cb-c0ad-5526e46eff8c@redhat.com> MIME-Version: 1.0 In-Reply-To: <7163c5db-3025-01cb-c0ad-5526e46eff8c@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 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.3 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 Mon, Feb 27, 2023 at 06:26:04PM -0500, Jason Merrill wrote: > > The following patch instead adds a target hook which allows the backend > > to temporarily tweak registered types such that emit_support_tinfos > > emits whatever is needed. > > Why handle these types differently from the DFP handling at the end of > emit_support_tinfos? One thing is that the fallback_* nodes look like a waste to me, the tinfo decls are mangled right away, and the fallback_* nodes need to be walked by GC, so I think we could get away even for the decimal tinfos to just do: dfloat32_type_node = make_node (REAL_TYPE); emit_support_tinfo_1 (dfloat32_type_node); dfloat32_type_node = NULL_TREE; etc. and drop the fallback stuff. If we wanted to do fallback_* even for the _Float*/decltype(0.0bf16) nodes, which are at least sometimes mangled in target hooks it would make stuff harder because fallback_* is C++ FE private. And then there is a question whether we want to emit rtti for _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless of whether the target supports them at all or not. Emitting them always would have an advantage, if say bfloat16_t support isn't added for aarch64 for GCC 13 (it is still pending review), we wouldn't need to deal with symbol versioning for it in GCC 14 or later. On the other side, on some arches some types are very unlikely to be supported. And e.g. _Float128x isn't supported on any arch right now. Though, if we can get rid of the fallback_* stuff and we wanted to emit all _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) tinfos on all arches (or say for now all but _Float128x), we could do it simply by splitting the fundamentals array in emit_support_tinfos into one without fallback and one with fallback, put say &dfloat32_type_node, &dfloat64_type_node, &dfloat128_type_node, &bfloat16_type_node, &float16_type_node, &float32_type_node, &float64_type_node, &float128_type_node, &float32x_type_node, &float64x_type_node, &float128x_type_node, 0 into the latter and simply handle the NULL case with a temporary fallback, like: tree fallback = NULL_TREE; for (ix = 0; fundamentals_with_fallback[ix]; ix++) if (*fundamentals_with_fallback[ix]) emit_support_tinfo_1 (*fundamentals_with_fallback[ix]); else { if (fallback == NULL_TREE) fallback = make_node (REAL_TYPE); *fundamentals_with_fallback[ix] = fallback; emit_support_tinfo_1 (fallback); *fundamentals_with_fallback[ix] = NULL_TREE; } Jakub