From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6EFDD1A1E27 for ; Mon, 1 Aug 2016 07:19:12 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f65so372171404wmi.0 for ; Mon, 01 Aug 2016 07:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=tjQGVpo7vJ7p9flwgipWWbAjI0FY9nDdRVNcGHrxp88=; b=ayEtv6k8+RRxYW78P3IhRO9Iq2Qxr32EyzsOJfhbq9daxevgFbW+yCd++ldaKADp/p KKsmtSr8Nb5rqJ1G8xNzKKbqfrbxwY4AtBgyvBdAMbejt/uqikOL5mJBF46/zXYL4U25 WhENrLk8dPgLDqhf6sfrvVKxp0ab40gRb8vBM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tjQGVpo7vJ7p9flwgipWWbAjI0FY9nDdRVNcGHrxp88=; b=PMkDIzJKDa5dhw3cFZ+gXh3GwMPutpCjYQ8lk9ZPLXLc/vu9JwmdI5FE+hXqsb9Fyn dVfFEw2kpvToVCDGklrSgeLnbIULKXMFjlPzDLrB8WgvEnG60DgpHe/XsS9e8rYqRju/ +welPZgoWTFXzOwIdWNBmsLzJ7kGji5DzQn9+2yZJnWK+PQXPCgdntLffVFRoInXj7pi tjsxvP9qmxePv6i5tQ+10FTRX+vRwDmvFq2Rshk7Qz+p55IMLr54sEmiL48PWIFAlf/I XfKmu2VewDJcv167Zvpcq1GxK4GbNnyxCotFUlebgsRwcaV8yKe4OEgmKAfTiE73JDIX u0tA== X-Gm-Message-State: AEkooutLRXNDHCrRHStBhRodridTuzvWRI7SiK7I5hpn1TmS/7YMJT5KoyrIjp085prpQyji X-Received: by 10.194.89.129 with SMTP id bo1mr22668533wjb.105.1470061150126; Mon, 01 Aug 2016 07:19:10 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id c8sm30812514wjm.19.2016.08.01.07.19.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 07:19:09 -0700 (PDT) Date: Mon, 1 Aug 2016 15:19:07 +0100 From: Leif Lindholm To: Ard Biesheuvel Cc: edk2-devel-01 , "Gao, Liming" , "Zhu, Yonghong" , "Cohen, Eugene" Message-ID: <20160801141907.GT31760@bivouac.eciton.net> References: <1469618762-7648-1-git-send-email-ard.biesheuvel@linaro.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [PATCH 1/2] BaseTools/GenFw AARCH64: convert ADRP to ADR if binary size allows it X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:19:12 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Apologies, lost track of this one. On Mon, Aug 01, 2016 at 01:53:09PM +0200, Ard Biesheuvel wrote: > On 27 July 2016 at 13:26, Ard Biesheuvel wrote: > > The ADRP instruction in the AArch64 ISA requires the link time and load > > time offsets of a binary to be equal modulo 4 KB. The reason is that this > > instruction always produces a multiple of 4 KB, and relies on a subsequent > > ADD or LDR instruction to set the offset into the page. The resulting > > symbol reference only produces the correct value if the symbol in question > > resides at that exact offset into the page, and so loading the binary at > > arbitrary offsets is not possible. > > > > Due to the various levels of padding when packing FVs into FVs into FDs, > > this alignment is very costly for XIP code, and so we would like to relax > > this alignment requirement if possible. > > > > Given that symbols that are sufficiently close (within 1 MB) of the > > reference can also be reached using an ADR instruction which does not > > suffer from this alignment issue, let's replace ADRP instructions with ADR > > after linking if the offset can be encoded in this instruction's immediate > > field. Note that this only makes sense if the section alignment is < 4 KB. > > Otherwise, replacing the ADRP has no benefit, considering that the > > subsequent ADD or LDR instruction is retained, and that micro-architectures > > are more likely to be optimized for ADRP/ADD pairs (i.e., via micro op > > fusing) than for ADR/ADD pairs, which are non-typical. > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Ard Biesheuvel > > @Liming, @Leif: > > are there any objections to these patches? I know it is unfortunate > that we need to modify instructions as part of the ELF to PE/COFF > conversion, but it is very effective It's absolutely horrid, but extremely useful. For the series: Reviewed-by: Leif Lindholm > ArmVirtQemu-AARCH64 built with CLANG35: > > Before: > > FVMAIN_COMPACT [41%Full] 2093056 total, 868416 used, 1224640 free > FVMAIN [99%Full] 4848064 total, 4848008 used, 56 free > > After: > > FVMAIN_COMPACT [36%Full] 2093056 total, 768064 used, 1324992 free > FVMAIN [99%Full] 4848064 total, 4848008 used, 56 free > > For comparision, GCC49 > > FVMAIN_COMPACT [35%Full] 2093056 total, 749960 used, 1343096 free > FVMAIN [99%Full] 3929088 total, 3929032 used, 56 free > > and GCC5 (with LTO) > > FVMAIN_COMPACT [34%Full] 2093056 total, 732400 used, 1360656 free > FVMAIN [99%Full] 3730240 total, 3730216 used, 24 free > > In other words, it turns CLANG35 from a pathetic outlier into > something usable :-) > > Regards, > Ard.