Since those data are assumed to be within the relocation offset limit.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
20828 | This function is getting kinda complex. And given we already have classifyLocalReference/classifyGlobalReference and friends, why does this function even need to look at GV and the CodeModel at all? That kinda feels wrong...Shouldn't it be entirely based on the OpFlags? That is, I'm kinda wondering why this function isn't, in its entirety just if (Subtarget.isPICStyleRIPRel() && OpFlags == X86II::MO_NO_FLAG) return X86ISD::WrapperRIP; if (OpFlags == X86II::MO_GOTPCREL || OpFlags == X86II::MO_GOTPCREL_NORELAX) return X86ISD::WrapperRIP; return X86ISD::Wrapper; Or do we actually emit references that are neither GOT nor pc-relative in PIC mode in some circumstances? (Which would, then, imply text relocations...which seems wrong...) |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
20826–20828 | I guess James suggested that we avoid looking at GV, which is how we knew we could do the rip-rel LEA previously. | |
llvm/test/CodeGen/X86/code-model-elf.ll | ||
303 | I think the old sequence is better, if we can get it. GCC does something weird: I think they assume the program is in the low 4GB of the address space if compiled without PIC. | |
346 | 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). | |
500 | Oh god, the large code model is so inefficient! Even the GOT offsets are potentially 64-bit. O_O |
I guess James suggested that we avoid looking at GV, which is how we knew we could do the rip-rel LEA previously.