maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/fold-add-pcrel.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

42 lines
1.6 KiB
LLVM
Raw Normal View History

[X86] matchAdd: don't fold a large offset into a %rip relative address For `ret i64 add (i64 ptrtoint (i32* @foo to i64), i64 1701208431)`, ``` X86DAGToDAGISel::matchAdd ... // AM.setBaseReg(CurDAG->getRegister(X86::RIP, MVT::i64)); if (!matchAddressRecursively(N.getOperand(0), AM, Depth+1) && // Try folding offset but fail; there is a symbolic displacement, so offset cannot be too large !matchAddressRecursively(Handle.getValue().getOperand(1), AM, Depth+1)) return false; ... // Try again after commuting the operands. // AM.Disp = Val; foldOffsetIntoAddress() does not know there will be a symbolic displacement if (!matchAddressRecursively(Handle.getValue().getOperand(1), AM, Depth+1) && // AM.setBaseReg(CurDAG->getRegister(X86::RIP, MVT::i64)); !matchAddressRecursively(Handle.getValue().getOperand(0), AM, Depth+1)) // Succeeded! Produced leaq sym+disp(%rip),... return false; ``` `foldOffsetIntoAddress()` currently does not know there is a symbolic displacement and can fold a large offset. The produced `leaq sym+disp(%rip), %rax` instruction is relocated by an R_X86_64_PC32. If disp is large and sym+disp-rip>=2**31, there will be a relocation overflow. This approach is still not elegant. Unfortunately the isRIPRelative interface is a bit clumsy. I tried several solutions and eventually picked this one. Differential Revision: https://reviews.llvm.org/D73606
2020-01-29 13:18:29 +08:00
; RUN: llc -mtriple=x86_64 -relocation-model=static < %s | FileCheck --check-prefixes=CHECK,STATIC %s
; RUN: llc -mtriple=x86_64 -relocation-model=pic < %s | FileCheck --check-prefixes=CHECK,PIC %s
; RUN: llc -mtriple=x86_64 -code-model=medium -relocation-model=static < %s | FileCheck --check-prefixes=CHECK,MSTATIC %s
; RUN: llc -mtriple=x86_64 -code-model=medium -relocation-model=pic < %s | FileCheck --check-prefixes=CHECK,MPIC %s
[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local For a MC_GlobalAddress reference to a dso_local external GlobalValue with a definition, emit .Lfoo$local to avoid a relocation. -fno-pic and -fpie can infer dso_local but -fpic cannot. In the future, we can explore the possibility of inferring dso_local with -fpic. As the description of D73228 says, LLVM's existing IPO optimization behaviors (like -fno-semantic-interposition) and a previous assembly behavior give us enough license to be aggressive here. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D73230
2020-01-23 04:27:17 +08:00
@foo = internal global i32 0
[X86] matchAdd: don't fold a large offset into a %rip relative address For `ret i64 add (i64 ptrtoint (i32* @foo to i64), i64 1701208431)`, ``` X86DAGToDAGISel::matchAdd ... // AM.setBaseReg(CurDAG->getRegister(X86::RIP, MVT::i64)); if (!matchAddressRecursively(N.getOperand(0), AM, Depth+1) && // Try folding offset but fail; there is a symbolic displacement, so offset cannot be too large !matchAddressRecursively(Handle.getValue().getOperand(1), AM, Depth+1)) return false; ... // Try again after commuting the operands. // AM.Disp = Val; foldOffsetIntoAddress() does not know there will be a symbolic displacement if (!matchAddressRecursively(Handle.getValue().getOperand(1), AM, Depth+1) && // AM.setBaseReg(CurDAG->getRegister(X86::RIP, MVT::i64)); !matchAddressRecursively(Handle.getValue().getOperand(0), AM, Depth+1)) // Succeeded! Produced leaq sym+disp(%rip),... return false; ``` `foldOffsetIntoAddress()` currently does not know there is a symbolic displacement and can fold a large offset. The produced `leaq sym+disp(%rip), %rax` instruction is relocated by an R_X86_64_PC32. If disp is large and sym+disp-rip>=2**31, there will be a relocation overflow. This approach is still not elegant. Unfortunately the isRIPRelative interface is a bit clumsy. I tried several solutions and eventually picked this one. Differential Revision: https://reviews.llvm.org/D73606
2020-01-29 13:18:29 +08:00
define dso_local i64 @zero() {
; CHECK-LABEL: zero:
; CHECK: # %bb.0:
; STATIC-NEXT: movl $foo, %eax
; STATIC-NEXT: retq
; PIC-NEXT: leaq foo(%rip), %rax
; PIC-NEXT: retq
; MSTATIC-NEXT: movabsq $foo, %rax
; MSTATIC-NEXT: retq
; MPIC-NEXT: leaq _GLOBAL_OFFSET_TABLE_(%rip), %rcx
; MPIC-NEXT: movabsq $foo@GOTOFF, %rax
; MPIC-NEXT: addq %rcx, %rax
entry:
ret i64 add (i64 ptrtoint (i32* @foo to i64), i64 0)
}
;; Check we don't fold a large offset into leaq, otherwise
;; the large r_addend can easily cause a relocation overflow.
define dso_local i64 @large() {
; CHECK-LABEL: large:
; CHECK: # %bb.0:
; STATIC-NEXT: movl $1701208431, %eax
; STATIC-NEXT: leaq foo(%rax), %rax
; PIC-NEXT: leaq foo(%rip), %rax
; PIC-NEXT: addq $1701208431, %rax
; MSTATIC-NEXT: movabsq $foo, %rax
; MSTATIC-NEXT: addq $1701208431, %rax
; MSTATIC-NEXT: retq
; MPIC-NEXT: leaq _GLOBAL_OFFSET_TABLE_(%rip), %rax
; MPIC-NEXT: movabsq $foo@GOTOFF, %rcx
; MPIC-NEXT: leaq 1701208431(%rax,%rcx), %rax
entry:
ret i64 add (i64 ptrtoint (i32* @foo to i64), i64 1701208431)
}