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 01B2E3857C4D for ; Fri, 28 Oct 2022 17:16:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 01B2E3857C4D 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=1666977367; 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=FRzamZy2onsDQErT12FvYyLctAs/alx+s704BKvuNtg=; b=fc6rOL29VSPfFT/9x4qasMyXZ6HqraB3JOBOIry/HmD230NZgPn4DpZof197TvTCGPKAMI dUCs4/g+PedUs9qHFiTkyxCxhmT9NDYoh9w61Czl386mizdcFGEBEWOr8EWSU5d54hv5Ks WjoDknEvb3bj7xXS3WkeJzbW+j4JS2Y= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-453-smE-bS1uNzmEzSGVHJk_fw-1; Fri, 28 Oct 2022 13:16:06 -0400 X-MC-Unique: smE-bS1uNzmEzSGVHJk_fw-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 06E831C05AAC; Fri, 28 Oct 2022 17:16:06 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B772A1121315; Fri, 28 Oct 2022 17:16:05 +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 29SHG3E52292731 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 28 Oct 2022 19:16:03 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29SHG2fv2292730; Fri, 28 Oct 2022 19:16:02 +0200 Date: Fri, 28 Oct 2022 19:16:01 +0200 From: Jakub Jelinek To: Patrick Palka Cc: Jonathan Wakely , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH] libstdc++: std::to_chars std::{,b}float16_t support Message-ID: Reply-To: Jakub Jelinek References: <4ba36955-3f9a-00c5-c406-45821ec2a4db@idea> MIME-Version: 1.0 In-Reply-To: <4ba36955-3f9a-00c5-c406-45821ec2a4db@idea> 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=-4.2 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 Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote: > IIRC for hex formatting of denormals I opted to be consistent with how > glibc printf formats them, instead of outputting the truly shortest > form. Note, it isn't just denormals, 1.18cp-4 2.318p-5 4.63p-6 8.c6p-7 463p-10 8c6p-11 also represent the same number, the first is what glibc emits (and is certainly nicer to read), but some of the others are shorter. Now, the printf %a/%A documentation says that there must be one hexadecimal digit before the dot if any and that for normalized numbers it must be non-zero. So that rules out the last 2, and allows but doesn't require the denormal treatment the library does right now. If we shall go really for the shortest, we should handle denormals with non-zero leading digit too and for all cases consider the 4 shifting possibilities which one results in shortest (perhaps prefer the smallest non-zero leading digit among the shortest)? > > readelf -Ws libstdc++.so.6.0.31 | grep float16_t > > 912: 00000000000ae824 950 FUNC GLOBAL DEFAULT 13 _ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format@@GLIBCXX_3.4.31 > > 5767: 00000000000ae4a1 899 FUNC GLOBAL DEFAULT 13 _ZSt20__to_chars_float16_tPcS_fSt12chars_format@@GLIBCXX_3.4.31 > > 842: 000000000016d430 106 FUNC LOCAL DEFAULT 13 _ZN12_GLOBAL__N_113get_ieee_reprINS_23floating_type_float16_tEEENS_6ieee_tIT_EES3_ > > 865: 0000000000170980 1613 FUNC LOCAL DEFAULT 13 _ZSt23__floating_to_chars_hexIN12_GLOBAL__N_123floating_type_float16_tEESt15to_chars_resultPcS3_T_St8optionalIiE.constprop.0.isra.0 > > 7205: 00000000000ae824 950 FUNC GLOBAL DEFAULT 13 _ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format > > 7985: 00000000000ae4a1 899 FUNC GLOBAL DEFAULT 13 _ZSt20__to_chars_float16_tPcS_fSt12chars_format > > so 3568 code bytes together or so. > > Ouch, the instantiation of __floating_to_chars_hex for float16 is > responsible for nearly 50% of the .so size increase True, but the increase isn't that huge. Jakub