From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id DC3E53858D38 for ; Thu, 13 Aug 2020 03:17:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DC3E53858D38 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-MImoc2ZMP7mc3vM-z0_18A-1; Wed, 12 Aug 2020 23:17:49 -0400 X-MC-Unique: MImoc2ZMP7mc3vM-z0_18A-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A7221800D55; Thu, 13 Aug 2020 03:17:48 +0000 (UTC) Received: from ovpn-112-97.phx2.redhat.com (ovpn-112-97.phx2.redhat.com [10.3.112.97]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5BCC55D6C2; Thu, 13 Aug 2020 03:17:48 +0000 (UTC) Message-ID: <55dc0bfbd282153fd9f1d1cfc4c4b8ad2507b1fd.camel@redhat.com> Subject: Re: LTO Optimization with asm renames of intrinsic functions From: Jeff Law Reply-To: law@redhat.com To: Paul E Murphy , gcc-help@gcc.gnu.org Date: Wed, 12 Aug 2020 21:17:47 -0600 In-Reply-To: <5d93203d-8f34-4f5e-8050-8a23396796b1@linux.ibm.com> References: <5d93203d-8f34-4f5e-8050-8a23396796b1@linux.ibm.com> Organization: Red Hat User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.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_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 03:17:54 -0000 On Wed, 2020-08-12 at 17:26 -0500, Paul E Murphy via Gcc-help wrote: > I ran into a slight divergence of behavior when enabling LTO using GCC > 10.2 or newer when building libdfp on x86 and ppc64. > > Libdfp builds a copy of libdecnumber which exports its own copy of ABI > as specified for _Decimal types in the GCC documentation. Some of this > ABI is implicitly used in libdfp to implement various facilities. > > These intrinsic calls generate PLT calls which should resolve to > symbols provided by libdfp. However, libdfp tries to avoid these > by inserting asm renames of the form: > > asm ("__bid_floatsidd = __GI___bid_floatsidd"); If you've got an ASM like this, then you can't use LTO. In simplest terms LTO doesn't look inside ASMs for symbol references and can't inherently do the right thing. You might be able to use the symver attribute to do renaming, but I don't know if anyone's tried it yet for anything other than specifying symbol versioning. jeff > >