From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id A051C3857C6E for ; Wed, 12 Aug 2020 22:26:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A051C3857C6E Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07CM2piR104405 for ; Wed, 12 Aug 2020 18:26:37 -0400 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 32v7p0ps3e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 12 Aug 2020 18:26:37 -0400 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 07CMJBVE005761 for ; Wed, 12 Aug 2020 22:26:36 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma03dal.us.ibm.com with ESMTP id 32skp9ebg4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 12 Aug 2020 22:26:36 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 07CMQaEC54788468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 12 Aug 2020 22:26:36 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 034E2112063 for ; Wed, 12 Aug 2020 22:26:36 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C2DD8112061 for ; Wed, 12 Aug 2020 22:26:35 +0000 (GMT) Received: from [9.211.47.231] (unknown [9.211.47.231]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP for ; Wed, 12 Aug 2020 22:26:35 +0000 (GMT) From: Paul E Murphy Subject: LTO Optimization with asm renames of intrinsic functions To: gcc-help@gcc.gnu.org Message-ID: <5d93203d-8f34-4f5e-8050-8a23396796b1@linux.ibm.com> Date: Wed, 12 Aug 2020 17:26:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-12_18:2020-08-11, 2020-08-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=1 malwarescore=0 phishscore=0 clxscore=1011 adultscore=0 mlxlogscore=219 lowpriorityscore=0 suspectscore=1 mlxscore=1 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008120140 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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: Wed, 12 Aug 2020 22:26:49 -0000 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"); Where the libdfp copy of such symbols are prefixed with __GI_ using the trick inherited from glibc. This creative workaround has worked with lto disabled, but when enabled, it is effectively ignored. Is there a more robust way to bypass plt calls for intrinsic functions when using LTO?