search for: adrps

...in LLVM trunk and it would be hard for me to verify any thoughts. The LOH solution is also orthogonal. You can see that as a last chance way to optimize those accesses. That said, if you CSE the ADRP and not the LOADGot, you will indeed create far less candidates for the LOHs because you will have ADRPs with several uses, which is not supported by LOHs. FYI, the LOH optimization is not a link-time optimization in LLVM, this is really a link-time optimization: on the binary. > > Any concrete suggestion of combining those different ADRP CSE solutions and tests would be appreciated! The bot...

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 x0, :got:var // relocation

...nd it would be hard for me to verify any thoughts. > > The LOH solution is also orthogonal. You can see that as a last chance way to optimize those accesses. > That said, if you CSE the ADRP and not the LOADGot, you will indeed create far less candidates for the LOHs because you will have ADRPs with several uses, which is not supported by LOHs. > > Yes. This is just what I'm worrying about. So essentially those two optimizations have conflict. Let us try to fix the codegen problem while keeping the pseudos. > > FYI, the LOH optimization is not a link-time optimization...

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 am not sure if such a thing is even possible or

On Fri, Feb 27, 2015 at 2:13 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Fri, Feb 27, 2015 at 1:42 PM, Eric Christopher <echristo at gmail.com> > wrote: > > > > > > On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com > > > > wrote: > >> > >> On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls

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

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

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

...ang 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 it was designed as a microarchitectural optimization so it's not guaranteed to trigger or be able to remove all adrps if it does. > As near as I can determine, ld.lld does not have this same feature. I am > wondering if I am missing something, if such a feature is being planned, MachO support in lld is pretty immature compared to ELF and it certainly doesn't look like it's supported yet. I'm af...

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

On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> > wrote: > > > > Hi Ahmed, > > > > Did you run these experiments on a platform with a linker that makes > > use of the AArch64CollectLOH-pass-produced information? > > As Jim says,

On Fri, Feb 27, 2015 at 1:42 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: >> >> On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> >> wrote: >> > >> > Hi Ahmed, >> > >> > Did you run these

Hello Eric, If you do decide to investigate the linker script route, the ALIGN builitin function might be useful. I think the simplest way is to do something like: .text ALIGN(0x1000) : { *(.text) } .my_next_section ALIGN (0x1000) : { *(my_next_section) } Bothe .text and .my_next_section would start at 4k boundaries. Link to docs:

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 the > Wednesday decided to get down to

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

I am developing in C for an extremely 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

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,...

On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Hi Ahmed, > > Did you run these experiments on a platform with a linker that makes > use of the AArch64CollectLOH-pass-produced information? As Jim says, I'm on iOS, so yes. However, I'm mostly running tests with the pass disabled. > > I'm guessing that the

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

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1