search for: auipc

...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 section. Now that you mention the MIPS & RISC-V alternatives, I'm not sure w...

...udo 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 in MIPS (16 bits multiplied by 65636 there). In all cases, if you then do an add immediate with a 12 bit signed literal (16 bit for MIPS) then you've got a relative offset from the current PC< accurate to the byte, anywhere in a +/-...

...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 section. > > Now that you mention the MIPS & RISC-V...

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

...gt; > "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 section. >> >> Now that...

...Linux. Not sure if anyone is working on this already, any inputs are very welcome. I'm now looking at function calls which in the RISCV backend are represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL. Currently those pseudos are lowered in MCCodeEmitter. They are expanded into AUIPC and JALR instructions and the first one needs a relocation, which for a static reloc model is R_RISCV_CALL but for PIC code should be R_RISCV_CALL_PLT. The problem I find is that at this point it is too late to tell the exact relocation needed: as far as I can tell there is no way to determine the...

...s0,8(sp) 4: c606 sw ra,12(sp) 6: 06300793 li a5,99 a: 842a mv s0,a0 c: 00a7cb63 blt a5,a0,22 <.L2> 10: 85aa mv a1,a0 12: 00000537 lui a0,0x0 16: 00050513 mv a0,a0 1a: 00000317 auipc t1,0x0 1e: 000300e7 jalr t1 00000022 <.L2>: 22: 40b2 lw ra,12(sp) 24: 8522 mv a0,s0 26: 4422 lw s0,8(sp) 28: 0141 addi sp,sp,16 2a: 8082 ret And after linking: 00010164 <foo>: 101...

On 2 Mar 2018, at 11:45, Nagaraju Mekala <nagaraju.mekala87 at gmail.com> wrote: > > yes they are dependent if the branch immediate value is > 0xffff then > the imm instruction should generate other wise only "br" instruction > is enough. This sounds as if you have two br instructions, one that takes an immediate and one that takes a register and requires that

On Fri, Mar 2, 2018 at 4:59 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 2 Mar 2018, at 11:09, Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I am working on a target which requires to generated two >> instructions for a single branch instruction. >> ex: >> imm 1 >> br r4,0xabcd >> branch

...06300793 li a5,99 >> a: 842a mv s0,a0 >> c: 00a7cb63 blt a5,a0,22 <.L2> >> 10: 85aa mv a1,a0 >> 12: 00000537 lui a0,0x0 >> 16: 00050513 mv a0,a0 >> 1a: 00000317 auipc t1,0x0 >> 1e: 000300e7 jalr t1 >> >> 00000022 <.L2>: >> 22: 40b2 lw ra,12(sp) >> 24: 8522 mv a0,s0 >> 26: 4422 lw s0,8(sp) >> 28: 0141 addi sp,sp,16 >> 2a: 808...

...gt; > "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 section. >> >> Now that...

Hi, Does lld support linker relaxation that may shrink code size? As far as I see lld seems to assume that the content of input sections to be fixed other than patching up relocations, but I believe some targets may benefit the extra optimization opportunity with relaxation. Specifically, I'm currently working on adding support for RISC-V in lld, and RISC-V heavily relies on linker relaxation

On Jan 19, 2017 2:48 AM, "Ed Maste" <emaste at freebsd.org> wrote: On 4 January 2017 at 13:34, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm about to start working on range extension thunks in lld. This is > an attempt to summarize the approach I'd like to take and what the > impact will be on lld outside of thunks. Now that LLD works