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 84A8B3858D33 for ; Wed, 1 Mar 2023 22:50:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 84A8B3858D33 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=1677711059; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2KKny4vYdS3C1+tZPkCL9I2S6hJB8akOo/pHICAPrao=; b=OfatovMoRqaCQuzCIYVNgWkYYKidk1DDteCCjyLqSe3zEvHIx5tbH8MxmM217ICux8jYu7 dkq3J2KyKsZjySQitD6djVK3Fg8YW/svfzAzfd8a9+P++jnjsIcLK48cYA0IliswKKUkfE dODbroVQIp/eLGokNI0ZMSCfrwNvV54= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-49-9bKjq-CUNCGgGecK7TYb6w-1; Wed, 01 Mar 2023 17:50:50 -0500 X-MC-Unique: 9bKjq-CUNCGgGecK7TYb6w-1 Received: by mail-qk1-f200.google.com with SMTP id eb13-20020a05620a480d00b00742be8a1a17so5632712qkb.18 for ; Wed, 01 Mar 2023 14:50:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677711050; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2KKny4vYdS3C1+tZPkCL9I2S6hJB8akOo/pHICAPrao=; b=r4G+UCFzf5zlmlh1vCNPOcS4OyT+aHbM43XHxfg9pNz4q6SK+m/5yHI+vrhXF72+2K kPOzmLWCJz0HZ0u6Z9AHNZTngUPdY3U5XWztV7+AY9sCxOMTGga/TPszjQ3Pj0GT28MH YMvTIBplHw10wcOs8VmFtwLxbShYUsYLt17fNKNEOG27syDInTDF3eS7b3vxfm0YUWGw k5j6sbhAxkSc3tgyrSIFIS82uOPdndqgQu0z2/fwx+yZMSz4uXrJOZX6icttzCu5z62l Isefws6w1TrmkaaOgkwaLpVQ3VMPSrbCqCnJyDZXOppBM4BJ3Pj1AbP9RnBeF4yrDbGH hchQ== X-Gm-Message-State: AO0yUKUMFM9LiMp8f5xqmE5bmjqmhHjslh+tRXyca0NKtoucmT5UvRbC aWChgl86rCz6gihfuw4hDkbFX/BTXjVlnrB12iUDjDL++PeE4+II3eYaARF7Up87nW7s0Ao38Hg lX+3B2OsL98B8OgKVtA== X-Received: by 2002:ac8:5bd6:0:b0:3bf:b8ae:fa7d with SMTP id b22-20020ac85bd6000000b003bfb8aefa7dmr14667210qtb.55.1677711050122; Wed, 01 Mar 2023 14:50:50 -0800 (PST) X-Google-Smtp-Source: AK7set+X05rhTSiOQPt0YzPiaHuIH++iKtNTBtV1hOy7h+EZuVQKbAx1COSopFcOJsWIZPtgP1OJCQ== X-Received: by 2002:ac8:5bd6:0:b0:3bf:b8ae:fa7d with SMTP id b22-20020ac85bd6000000b003bfb8aefa7dmr14667192qtb.55.1677711049815; Wed, 01 Mar 2023 14:50:49 -0800 (PST) Received: from [192.168.1.108] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id p9-20020a05620a056900b007423caef02fsm9590178qkp.122.2023.03.01.14.50.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Mar 2023 14:50:49 -0800 (PST) Message-ID: Date: Wed, 1 Mar 2023 17:50:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] c++: Add target hook for emit_support_tinfos [PR108883] To: Jakub Jelinek Cc: Jonathan Wakely , gcc-patches@gcc.gnu.org References: <7163c5db-3025-01cb-c0ad-5526e46eff8c@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 2/27/23 18:51, Jakub Jelinek wrote: > 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. I think you're right. > 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. A good point. Incidentally, it seems problematic for embedded users that all the fundamental type_infos are emitted in the same .o, making it hard to link in only the ones you care about. And new floating-point variants add to that problem. So perhaps until that is addressed, it's better to avoid adding a bunch more on targets that don't support them. Hmm. > 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 >