[X86] Don't respect large data threshold for globals with an explicit section

[aeubanks]

If multiple globals are placed in an explicit section, there's a chance
that the large data threshold will cause the different globals to be
inconsistent in whether they're large or small. Mixing sections with
mismatched large section flags can cause undesirable issues like
increased relocation pressure because there may be 32-bit references to
the section in some TUs, but the section is considered large since input
section flags are unioned and other TUs added the large section flag.

An explicit code model on the global still overrides the decision. We
can do this for globals without any references to them, like what we did
with asan_globals in #74514. If we have some precompiled small code
model files where asan_globals is not considered large mixed with
medium/large code model files, that's ok because the section is
considered large and placed farther. However, overriding the code model
for globals in some TUs but not others and having references to them
from code will still result in the above undesired behavior.

This mitigates a whole class of mismatched large section flag issues
like what #77986 was trying to fix.

This ends up not adding the SHF_X86_64_LARGE section flag on explicit
sections in the medium/large code model. This is ok for the large code
model since all references from large text must use 64-bit relocations
anyway.

[llvmbot]

@llvm/pr-subscribers-backend-x86

Author: Arthur Eubanks (aeubanks)

Changes

If multiple globals are placed in an explicit section, there's a chance
that the large data threshold will cause the different globals to be
inconsistent in whether they're large or small. Mixing sections with
mismatched large section flags can cause undesirable issues like
increased relocation pressure because there may be 32-bit references to
the section in some TUs, but the section is considered large since input
section flags are unioned and other TUs added the large section flag.

An explicit code model on the global still overrides the decision. We
can do this for globals without any references to them, like what we did
with asan_globals in #74514. If we have some precompiled small code
model files where asan_globals is not considered large mixed with
medium/large code model files, that's ok because the section is
considered large and placed farther. However, overriding the code model
for globals in some TUs but not others and having references to them
from code will still result in the above undesired behavior.

This mitigates a whole class of mismatched large section flag issues
like what #77986 was trying to fix.

This ends up not adding the SHF_X86_64_LARGE section flag on explicit
sections in the medium/large code model. This is ok for the large code
model since all references from large text must use 64-bit relocations
anyway.

---

Full diff: https://github.com/llvm/llvm-project/pull/78348.diff

2 Files Affected:

• (modified) llvm/lib/Target/TargetMachine.cpp (+8-2)
• (modified) llvm/test/CodeGen/X86/code-model-elf-sections.ll (+6-6)

diff --git a/llvm/lib/Target/TargetMachine.cpp b/llvm/lib/Target/TargetMachine.cpp
index 2a4383314e4656..48a99dca0a6c9b 100644
--- a/llvm/lib/Target/TargetMachine.cpp
+++ b/llvm/lib/Target/TargetMachine.cpp
@@ -83,8 +83,14 @@ bool TargetMachine::isLargeGlobalValue(const GlobalValue *GVal) const {
       return true;
   }
 
-  if (getCodeModel() == CodeModel::Medium ||
-      getCodeModel() == CodeModel::Large) {
+  // Respect large data threshold for medium and large code models.
+  // ... But only for globals without an explicit section. If multiple globals
+  // are placed in an explicit section, there's a good chance that the data
+  // threshold will cause the different globals to be inconsistent in whether
+  // they're large or small. Mixing large section flags can cause undesirable
+  // issues like increased relocation pressure.
+  if (!GV->hasSection() && (getCodeModel() == CodeModel::Medium ||
+                            getCodeModel() == CodeModel::Large)) {
     if (!GV->getValueType()->isSized())
       return true;
     const DataLayout &DL = GV->getParent()->getDataLayout();
diff --git a/llvm/test/CodeGen/X86/code-model-elf-sections.ll b/llvm/test/CodeGen/X86/code-model-elf-sections.ll
index 749d5b6bf904e5..fc5dac89a6b3d3 100644
--- a/llvm/test/CodeGen/X86/code-model-elf-sections.ll
+++ b/llvm/test/CodeGen/X86/code-model-elf-sections.ll
@@ -55,13 +55,13 @@
 
 ; LARGE: .data {{.*}} WA {{.*}}
 ; LARGE: .data.x {{.*}} WA {{.*}}
-; LARGE: .data0 {{.*}} WAl {{.*}}
+; LARGE: .data0 {{.*}} WA {{.*}}
 ; LARGE: .ldata {{.*}} WAl {{.*}}
 ; LARGE: .ldata.x {{.*}} WAl {{.*}}
-; LARGE: .ldata0 {{.*}} WAl {{.*}}
+; LARGE: .ldata0 {{.*}} WA {{.*}}
 ; LARGE: force_small {{.*}} WA {{.*}}
 ; LARGE: force_large {{.*}} WAl {{.*}}
-; LARGE: foo {{.*}} WAl {{.*}}
+; LARGE: foo {{.*}} WA {{.*}}
 ; LARGE: .bss {{.*}} WA {{.*}}
 ; LARGE: .lbss {{.*}} WAl {{.*}}
 ; LARGE: .rodata {{.*}} A {{.*}}
@@ -72,14 +72,14 @@
 
 ; LARGE-DS: .data {{.*}} WA {{.*}}
 ; LARGE-DS: .data.x {{.*}} WA {{.*}}
-; LARGE-DS: .data0 {{.*}} WAl {{.*}}
+; LARGE-DS: .data0 {{.*}} WA {{.*}}
 ; LARGE-DS: .ldata {{.*}} WAl {{.*}}
 ; LARGE-DS: .ldata.x {{.*}} WAl {{.*}}
-; LARGE-DS: .ldata0 {{.*}} WAl {{.*}}
+; LARGE-DS: .ldata0 {{.*}} WA {{.*}}
 ; LARGE-DS: .ldata.data {{.*}} WAl {{.*}}
 ; LARGE-DS: force_small {{.*}} WA {{.*}}
 ; LARGE-DS: force_large {{.*}} WAl {{.*}}
-; LARGE-DS: foo {{.*}} WAl {{.*}}
+; LARGE-DS: foo {{.*}} WA {{.*}}
 ; LARGE-DS: .bss {{.*}} WA {{.*}}
 ; LARGE-DS: .lbss.bss {{.*}} WAl {{.*}}
 ; LARGE-DS: .rodata {{.*}} A {{.*}}

[rnk]

I'm in favor of this direction. We discussed and considered the other options, and this seems like the best approach to me.

[rnk]

Thanks!