From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 86D9A3858D28 for ; Mon, 3 Jul 2023 16:57:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 86D9A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EBDE62F4; Mon, 3 Jul 2023 09:58:07 -0700 (PDT) Received: from [10.2.78.54] (e120077-lin.cambridge.arm.com [10.2.78.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 73C7A3F663; Mon, 3 Jul 2023 09:57:24 -0700 (PDT) Message-ID: <33c6c1a6-ca51-bf57-fdcd-d62b738a6f99@arm.com> Date: Mon, 3 Jul 2023 17:57:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: wishlist: support for shorter pointers Content-Language: en-GB To: =?UTF-8?Q?Rafa=c5=82_Pietrak?= , Ian Lance Taylor Cc: Martin Uecker , "gcc@gcc.gnu.org" References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <112e711791835d56cca38654f83a009cb46707d4.camel@gwdg.de> <940e9ae5-8649-5a28-e29f-06f0b2982892@ztk-rp.eu> From: "Richard Earnshaw (lists)" In-Reply-To: <940e9ae5-8649-5a28-e29f-06f0b2982892@ztk-rp.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3492.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 03/07/2023 17:42, Rafał Pietrak via Gcc wrote: > Hi Ian, > > W dniu 3.07.2023 o 17:07, Ian Lance Taylor pisze: >> On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc >> wrote: > [--------] >>> I was thinking about that, and it doesn't look as requiring that deep >>> rewrites. ABI spec, that  could accomodate the functionality could be as >>> little as one additional attribute to linker segments. >> >> If I understand correctly, you are looking for something like the x32 >> mode that was available for a while on x86_64 processors: >> https://en.wikipedia.org/wiki/X32_ABI .  That was a substantial amount >> of work including changes to the compiler, assembler, linker, standard >> library, and kernel.  And at least to me it's never seemed >> particularly popular. > > Yes. > > And WiKi reporting up to 40% performance improvements in some corner > cases is impressive and encouraging. I believe, that the reported > average of 5-8% improvement would be significantly better within MCU > tiny resources environment. In MCU world, such improvement could mean > fit-nofit of a project into a particular device. > > -R I think you need to be very careful when reading benchmarketing (sic) numbers like this. Firstly, this is a 32-bit vs 64-bit measurement; secondly, the benchmark (spec 2000) is very old now and IIRC was not fully optimized for 64-bit processors (it predates the 64-bit version of the x86 instruction set); thirdly, there are benchmarks in SPEC which are very sensitive to cache size and the 32-bit ABI just happened to allow them to fit enough data in the caches to make the numbers leap. R.