search for: pcrel

While implementing a MachineFunctionPass that runs as part of the ARMTargetMachine::addPreEmitPass(), I've run into a problem. This particular MFP can drastically increase the size (in MachineInstr count) of the MachineFunction that it processes, so much so that there is a real danger of pcrel calls and branches that use immediate offsets to not be sufficient. A naive test confirmed that under extreme duress, LLVM does not produce correct BL/B sequences, as it defaults to using pcrel immediates which do not have enough bits to encode the offset. How do I convince LLVM to revert to mate...

Hi everyone, happy new year. This note is to announce that support for PC relative reloc tags for movw/movt is nearing completion (hopefully <48hrs!). This work is is from Jan Voung, David Meyer and myself. Unfortunately, to test this change, we need to patch ARM/AsmParser to address http://llvm.org/bugs/show_bug.cgi?id=8721 Locally, we have hacked up a solution to 8721, but its not ideal

On 10 January 2011 22:59, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, happy new year. > > This note is to announce that support for PC relative reloc tags for > movw/movt is nearing completion (hopefully <48hrs!). This work is is > from Jan Voung, David Meyer and myself. Hi Jason, Happy new year! That seems a long patch... with many changes... can't

-llvmcommits On Mon, Jan 10, 2011 at 3:21 PM, Renato Golin <renato.golin at arm.com> wrote: > Btw, I know this is for ELF printing, but can the same infrastructure > you're using to print the hi/lo be used to print relocation in Asm > output? Or is this a completely separate subject? Hi Renato, If I am understanding you correctly, then the answer is no, because .s output

On 10 January 2011 23:54, Jason Kim <jasonwkim at google.com> wrote: > If I am understanding you correctly, then the answer is no, because .s > output doesn't care about relocations per se... Hi Jason, That's not entirely true. ;) If you only use the GNU toolchain, that is correct. However, CodeSourcery's GCC changed a bit on how it works for ARM because the ARM toolchain

...CIE Augmentation .byte 1 ## CIE Code Alignment Factor .byte 120 ## CIE Data Alignment Factor .byte 16 ## CIE Return Address Column .byte 2 ## Augmentation Size .byte 16 ## LSDA Encoding = pcrel .byte 16 ## FDE Encoding = pcrel But the FDE has: .byte 0 ## Augmentation size The linker is expecting that since the CIE said there was an LSDA in each FDE that is pcrel encoded, that there would in fact be an LSDA in each FDE. But in this case, t...

Hi, If I type define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 1) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc(i64) declare void @llvm.gcroot(i8**, i8*) nounwind in test.ll and then do > llc test.ll > gcc test.s I get the error ld: in

...# CIE Data Alignment Factor .byte 16 # CIE Return Address Column .uleb128 7 # Augmentation Size .byte 27 # Personality (pcrel sdata4) .Lpersonalityref_addr1_0: .long personality-.Lpersonalityref_addr1_0 # Personality .byte 27 # LSDA Encoding (pcrel sdata4) .byte 27 # FDE Encoding (pcrel sda...

...byte 1 ## CIE Code Alignment Factor > .byte 120 ## CIE Data Alignment Factor > .byte 16 ## CIE Return Address Column > .byte 2 ## Augmentation Size > .byte 16 ## LSDA Encoding = pcrel > .byte 16 ## FDE Encoding = pcrel > > > But the FDE has: > > .byte 0 ## Augmentation size > > The linker is expecting that since the CIE said there was an LSDA in each FDE that is pcrel encoded, that there would in fact be a...

...e 16 > # CIE Return > Address Column > .uleb128 7 # Augmentation > Size > .byte 27 > # Personality > (pcrel sdata4) > .Lpersonalityref_addr1_0: > .long personality-.Lpersonalityref_addr1_0 # Personality > .byte 27 > # LSDA Encoding > (pcrel sdata4) > .byte 27 >...

Hi, I'm trying to get exception handling working in my compiler targetting LLVM. I've been working from the LLVM exception handling documentation (including http://llvm.org/docs/ExceptionHandling.html and http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism) and looking at g++-llvm's output. I've been trying to get a minimal test function to work, which simply invokes

...## CIE Code Alignment Factor >> .byte 120 ## CIE Data Alignment Factor >> .byte 16 ## CIE Return Address Column >> .byte 2 ## Augmentation Size >> .byte 16 ## LSDA Encoding = pcrel >> .byte 16 ## FDE Encoding = pcrel >> >> >> But the FDE has: >> >> .byte 0 ## Augmentation size >> >> The linker is expecting that since the CIE said there was an LSDA in each FDE that is pcrel encoded, t...

..._ir_emit_gk110.cpp index 6bb9620..28081fa 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp @@ -1316,6 +1316,8 @@ CodeEmitterGK110::emitFlow(const Instruction *i) } else if (mask & 2) { int32_t pcRel = f->target.bb->binPos - (codeSize + 8); + if (writeIssueDelays && !(f->target.bb->binPos & 0x3f)) + pcRel += 8; // currently we don't want absolute branches assert(!f->absolute); code[0] |= (pcRel & 0x1ff) << 23; diff --git...

...# CIE Return >> Address Column >> .uleb128 7 # Augmentation >> Size >> .byte 27 >> # Personality >> (pcrel sdata4) >> .Lpersonalityref_addr1_0: >> .long personality-.Lpersonalityref_addr1_0 # Personality >> .byte 27 >> # LSDA Encoding >> (pcrel sdata4) >> .byte 27 >>...

...;s a small problem that's brewing with the exception handling stuff that some of us have been working on lately. The problem is that different architectures are going to require different data format encodings for different exception handling bits. For example, one architecture may want PCREL for an entry, while another may want PCREL + SDATA4. There is a problem with the comment line for such information in the ASM file. We currently only have a mechanism in place to emit a string as a comment followed by EOL. The attached patch is an attempt to follow what GCC does. And by at...

Hi Bill, > I'm compiling this trivial program on Darwin: > > int main(int argc, char **argv) { > try { > throw argc; > } catch(int i) { > return i; > } > > return 0; > } > > However, it segfaults when I run it. I've attached the .s files > generated by LLVM and GCC, but it looks as if LLVM isn't generating a >

...t; entry. (It also isn’t quite right; PC32 can trigger the creation of a > PLT entry, which doesn’t entirely match what the ConstantExpr arithmetic > is doing.) > > Design > > A relocation can be seen as having three inputs: the relocation type (on > Mach-O this also includes a pcrel flag), the target, and the addend. So > let’s define a relocation constant like this: > > iNN reloc relocation_type (ptr target, iNN addend) > > where iNN is some integer type, and ptr is some pointer type. For example, > an ARM jump table entry might look like this: > > i32...

...llq __ZN3BobC1Ev leaq -24(%rbp), %rdi callq __ZN3BobC1Ev Ltmp0: callq __Z3foov Ltmp1: <snip> .section __TEXT,__gcc_except_tab .align 2 GCC_except_table0: Lexception0: .byte 255 ## @LPStart Encoding = omit .byte 155 ## @TType Encoding = indirect pcrel sdata4 .byte 156 ## @TType base offset .space 1 .byte 3 ## Call site Encoding = udata4 .byte 26 ## Call site table length ## >> Call Site 1 <<...

...used to represent an ARM jump table entry. (It also isn’t quite right; PC32 can trigger the creation of a PLT entry, which doesn’t entirely match what the ConstantExpr arithmetic is doing.) Design A relocation can be seen as having three inputs: the relocation type (on Mach-O this also includes a pcrel flag), the target, and the addend. So let’s define a relocation constant like this: iNN reloc relocation_type (ptr target, iNN addend) where iNN is some integer type, and ptr is some pointer type. For example, an ARM jump table entry might look like this: i32 reloc 0x1d (void ()* @foo, i32 0xeaf...

...) { printf("%s\n", s); } } GCC outputs this: [Irk:llvm] gcc-4.2 -S -o - -dA t.cpp -O3 .text .align 4,0x90 .globl __Z3foov __Z3foov: . . . LEHB0: call __Z3bazv LEHE0: . . . GCC_except_table0: LLSDA8: .byte 0xff # @LPStart format (omit) .byte 0x9b # @TType format (indirect pcrel sdata4) .byte 0x25 # uleb128 0x25; @TType base offset .byte 0x3 # call-site format (udata4) .byte 0x1a # uleb128 0x1a; Call-site table length .set L$set$0,LEHB0-LFB8 .long L$set$0 # region 0 start .set L$set$1,LEHE0-LEHB0 .long L$set$1 # length .set L$set$2,L6-LFB8 .long L$set$2 # landing...