search for: adrp

Hi Jiangning, On Apr 14, 2014, at 10:31 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Jim, > > 2014-04-15 4:28 GMT+08:00 Jim Grosbach <grosbach at apple.com>: > This sounds reasonable. Thanks, all. > > > - CSE of ADRP optimization (Jiangning) > > Quentin may have some input here. He’s done quite a lot of optimizations for ADRP sequences. > > -Jim > > ​Thanks for letting me ​know Quentin may have deep thought around this. > > ​ARM64 generates pseudo instructions ARM64::MOVaddr and frie...

Hello Eric, My understanding is that the ADRP instruction isn't supposed to be used on its own. The result of the ADRP provides a 4k aligned address, the following instruction such as an LDR has an immediate offset that can reach any address within the 4k page. For example to get the address of a global variable var with -fpic in ELF: adrp...

...2 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Quentin, > > Thanks for your feedback! >> ​ARM64 generates pseudo instructions ARM64::MOVaddr and friends in ISEL stage, which intends to guarantee address serialization (page address + in-page address), and exposes adrp finally by pass ExpandPseudoInsts. The assumption of ARM64 solution is we don't know the in-page offset can be fused into load/store or not at compile time, and this assumption would turn to be not true any longer for the solution of using global merge as I proposed with the patch. > I think...

Thank you for providing the explanation for how ADRP works...something I should have done myself. With this explanation in hand, one other alternative I was looking at was using a linkerscript to essentially rebase the code and have ADRP instructions that would address the correct location as a result. However, I am not a linkerscript expert, so I a...

...the AArch64CollectLOH-pass information and a linker > >> > that makes use of that information could affect the profitability of > >> > the GlobalMerge pass? > >> > >> It could, and does, from what I've seen (beware anecdata): > >> - reusing the adrp base prevents optimizing it (the various > >> Adrp*{ldr,str} LOHs). > >> - reusing the adrp+add MergedGlobal pointer, with indexed addressing, > >> doesn't prevent the AdrpAdd optimization. > >> > >> All in all, whether GlobalMerge is profitable or n...

Hello, I am working in an embedded environment with somewhat restrictive memory requirements where the page alignment requirements of an ADRP instruction cannot be guaranteed. With the ld program inside of the Xcode, there is a -preload flag which causes ADRP instructions to be dropped, and generates code that is 100% position independent. As near as I can determine, ld.lld does not have this same feature. I am wondering if I am missin...

On 21 May 2018 at 13:57, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > "ADRL produces position-independent code, because the address is calculated > relative to PC." > > From this, I'd expect ADRP to simply do Xd <- PC + n*4096, where n is a 20 > bit number, just like AUIPC in RISC-V (also a 20 literal multiplied by 4096) > or AUIPC in MIPS (16 bits multiplied by 65636 there). Afraid not. It really is (PC & ~0xfff) + n * 0x1000. So it does require 12-bit alignment of any code s...

Are you sure about that? In the documentation for the ADRL pseudo it says: "ADRL assembles to two instructions, an ADRP followed by ADD." "ADRL produces position-independent code, because the address is calculated relative to PC." >From this, I'd expect ADRP to simply do Xd <- PC + n*4096, where n is a 20 bit number, just like AUIPC in RISC-V (also a 20 literal multiplied by 4096) or AUIPC...

Hi Eric, On 21 May 2018 at 13:31, Eric Gorr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am working in an embedded environment with somewhat restrictive memory > requirements where the page alignment requirements of an ADRP instruction > cannot be guaranteed. It sounds like you're relying on the linker optimization hints that Clang emits. As you've seen they're designed to allow the linker to convert adrp/add pairs into simpler nop/ldr sequences. If it works for your purposes, great; but bear in mind i...

On 21 May 2018 at 14:52, Peter Smith <peter.smith at linaro.org> wrote: > The resulting code section is 4 byte aligned, I'm not sure where the > requirement for 4k aligned sections come from unless you are planning > to use ADRP alone? I think it's the segments that need to be 4K aligned (i.e. after linking). Normally this isn't really an extra constraint because you're just going to map them in with the MMU anyway, but in strange embedded situations I could see it being a problem. Consider the fully linked s...

...t; > > > > I'm guessing that the AArch64CollectLOH-pass information and a linker > > that makes use of that information could affect the profitability of > > the GlobalMerge pass? > > It could, and does, from what I've seen (beware anecdata): > - reusing the adrp base prevents optimizing it (the various > Adrp*{ldr,str} LOHs). > - reusing the adrp+add MergedGlobal pointer, with indexed addressing, > doesn't prevent the AdrpAdd optimization. > > All in all, whether GlobalMerge is profitable or not (by increasing > register pressure, or...

...t; I'm guessing that the AArch64CollectLOH-pass information and a linker >> > that makes use of that information could affect the profitability of >> > the GlobalMerge pass? >> >> It could, and does, from what I've seen (beware anecdata): >> - reusing the adrp base prevents optimizing it (the various >> Adrp*{ldr,str} LOHs). >> - reusing the adrp+add MergedGlobal pointer, with indexed addressing, >> doesn't prevent the AdrpAdd optimization. >> >> All in all, whether GlobalMerge is profitable or not (by increasing >&gt...

...t and .my_next_section would start at 4k boundaries. Link to docs: https://sourceware.org/binutils/docs/ld/Builtin-Functions.html#Builtin-Functions Peter On 21 May 2018 at 14:23, Eric Gorr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Thank you for providing the explanation for how ADRP works...something I > should have done myself. > > With this explanation in hand, one other alternative I was looking at was > using a linkerscript to essentially rebase the code and have ADRP > instructions that would address the correct location as a result. However, I > am not...

This sounds reasonable. Thanks, all. > - CSE of ADRP optimization (Jiangning) Quentin may have some input here. He’s done quite a lot of optimizations for ADRP sequences. -Jim On Apr 12, 2014, at 12:08 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi again, > > Having heard no howls of protest, those of us remaining on...

hi, does anyone know how to resolve this? It's a very simple IR file (below), fails with: LLVM ERROR: invalid symbol kind for ADRP relocation PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: \p\llvm-project-bin32\RelWithDebInfo\bin\llc.exe -O0 debug_output(1).ll -filetype=obj #0 0x01522349 (C:\p\llvm-project-bin32\RelWithDebInfo\bin\llc.exe+0x1272349...

...ly memory constrained AARCH64 embedded environment. Sometime between llvm 6 and 7, I'm seeing a code size regression when I make multiple accesses into a global struct. Specifically, I have functions that perform several reads/writes into this global struct. In older versions (5/6) - a single ADRP/ADD combo is issued at the beginning of a function to get my structure address into a register - that register is preserved throughout the function - subsequent accesses into this structure are done as LDR/STR with offset from the preserved register In later versions (7/8) - the ADRP/ADD combo is...

I did a bit more poking, using llvm/clang versions 6-8. The IR in all cases appears fundamentally identical. I ran the IR generated by version 6 through llc on all three versions. llc-7/8 produced the extra ADRPs, llc-6 did not. So (to my untrained eyes), the IR is generated the same, it is in the IR->AARCH64 asm pass that the extra instructions are being generated. On Wed, May 15, 2019 at 11:39 AM Florian Hahn <florian_hahn at apple.com> wrote: > Hi, > > > On May 15, 2019, at 16:27...

...nning tests with the pass disabled. > > I'm guessing that the AArch64CollectLOH-pass information and a linker > that makes use of that information could affect the profitability of > the GlobalMerge pass? It could, and does, from what I've seen (beware anecdata): - reusing the adrp base prevents optimizing it (the various Adrp*{ldr,str} LOHs). - reusing the adrp+add MergedGlobal pointer, with indexed addressing, doesn't prevent the AdrpAdd optimization. All in all, whether GlobalMerge is profitable or not (by increasing register pressure, or adding another indirection),...

Hi Ahmed, Did you run these experiments on a platform with a linker that makes use of the AArch64CollectLOH-pass-produced information? I'm guessing that the AArch64CollectLOH-pass information and a linker that makes use of that information could affect the profitability of the GlobalMerge pass? Thanks, Kristof > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu

...nknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1 sub sp, sp, #48 2d4c4: fd 7b 02 a9 stp x29, x30, [sp, #32] 2d4c8: fd 83 00 91 add x29, sp, #32 2d4cc: 08 01 00 d0 adrp x8, #139264 2d4d0: 08 49 47 f9 ldr x8, [x8, #3728] 2d4d4: 49 d0 3b d5 mrs x9, TPIDR_EL0 2d4d8: 28 69 68 f8 ldr x8, [x9, x8] 2d4dc: 08 7d 40 b2 orr x8, x8, #0xffffffff 2d4e0: 08 05 00 91...