[PATCH] D150297: [X86] Use RIP-relative addressing for data under large data threshold for medium code model

[Reid Kleckner via Phabricator via llvm-commits]

rnk added inline comments.


================
Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:20937-20939
-  // In the medium model, functions can always be referenced RIP-relatively,
-  // since they must be within 2GiB. This is also possible in non-PIC mode, and
-  // shorter than the 64-bit absolute immediate that would otherwise be emitted.
----------------
I guess James suggested that we avoid looking at GV, which is how we knew we could do the rip-rel LEA previously.


================
Comment at: llvm/test/CodeGen/X86/code-model-elf.ll:401
 ; MEDIUM-STATIC:       # %bb.0:
-; MEDIUM-STATIC-NEXT:    leaq static_fn(%rip), %rax
+; MEDIUM-STATIC-NEXT:    movabsq $static_fn, %rax
 ; MEDIUM-STATIC-NEXT:    retq
----------------
I think the old sequence is better, if we can get it. GCC does something weird:
https://gcc.godbolt.org/z/xPT49jqrT

I think they assume the program is in the low 4GB of the address space if compiled without PIC.


================
Comment at: llvm/test/CodeGen/X86/code-model-elf.ll:444
 ; MEDIUM-STATIC:       # %bb.0:
-; MEDIUM-STATIC-NEXT:    leaq global_fn(%rip), %rax
+; MEDIUM-STATIC-NEXT:    movabsq $global_fn, %rax
 ; MEDIUM-STATIC-NEXT:    retq
----------------
This seems undesirable. We should know that because global_fn is code, it is within 2GB of the current PC, so we can use the RIP, which has a smaller encoding (32-bit vs 64-bit).


================
Comment at: llvm/test/CodeGen/X86/code-model-elf.ll:500
 ; LARGE-PIC-NEXT:    addq %rax, %rcx
 ; LARGE-PIC-NEXT:    movabsq ${{\.?LCPI[0-9]+_[0-9]+}}@GOTOFF, %rax
 ; LARGE-PIC-NEXT:    addss (%rcx,%rax), %xmm0
----------------
Oh god, the large code model is so inefficient! Even the GOT offsets are potentially 64-bit. O_O


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150297/new/

https://reviews.llvm.org/D150297