[clang] [llvm] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)

2023-12-15 Thread Arthur Eubanks via cfe-commits

https://github.com/aeubanks closed 
https://github.com/llvm/llvm-project/pull/75542
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)

2023-12-15 Thread Arthur Eubanks via cfe-commits

https://github.com/aeubanks updated 
https://github.com/llvm/llvm-project/pull/75542

>From 884347b73d68e2d469b3903f248e72921434 Mon Sep 17 00:00:00 2001
From: Arthur Eubanks 
Date: Thu, 14 Dec 2023 15:41:31 -0800
Subject: [PATCH 1/3] [Instrumentation][X86] Limit setting large section flag
 to medium/large code models

In #74514 and #74778 we marked various instrumentation-added sections as
large. This causes an extra PT_LOAD segment if using the small code
model. Since people using the small code model presumably aren't hitting
relocation limits, disable this when using the small code model to avoid
the extra segment.

This is annoying API-wise because we need to pass TargetMachine around
to any pass that wants to do this. Module::getCodeModel(), like anything
else that reads Module metadata, is unreliable as a source of truth.
---
 clang/lib/CodeGen/BackendUtil.cpp | 10 -
 .../include/llvm/Transforms/Instrumentation.h |  6 --
 .../Instrumentation/AddressSanitizer.h|  5 -
 .../Instrumentation/InstrProfiling.h  |  9 +---
 llvm/lib/Passes/PassBuilderPipelines.cpp  |  4 ++--
 llvm/lib/Passes/PassRegistry.def  |  4 ++--
 .../Instrumentation/AddressSanitizer.cpp  | 21 +++
 .../Instrumentation/InstrProfiling.cpp| 16 +++---
 .../Instrumentation/Instrumentation.cpp   | 19 -
 .../global_metadata_code_model.ll |  4 +++-
 .../InstrProfiling/icall-comdat.ll| 21 ++-
 11 files changed, 72 insertions(+), 47 deletions(-)

diff --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 7d16de33763a0d..49de29e6580e3f 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -635,7 +635,7 @@ static void addKCFIPass(const Triple , const 
LangOptions ,
   });
 }
 
-static void addSanitizers(const Triple ,
+static void addSanitizers(const TargetMachine *TM, const Triple ,
   const CodeGenOptions ,
   const LangOptions , PassBuilder ) {
   auto SanitizersCallback = [&](ModulePassManager ,
@@ -696,7 +696,7 @@ static void addSanitizers(const Triple ,
 Opts.Recover = CodeGenOpts.SanitizeRecover.has(Mask);
 Opts.UseAfterScope = CodeGenOpts.SanitizeAddressUseAfterScope;
 Opts.UseAfterReturn = CodeGenOpts.getSanitizeAddressUseAfterReturn();
-MPM.addPass(AddressSanitizerPass(Opts, UseGlobalGC, UseOdrIndicator,
+MPM.addPass(AddressSanitizerPass(TM, Opts, UseGlobalGC, 
UseOdrIndicator,
  DestructorKind));
   }
 };
@@ -973,7 +973,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
 // Don't add sanitizers if we are here from ThinLTO PostLink. That already
 // done on PreLink stage.
 if (!IsThinLTOPostLink) {
-  addSanitizers(TargetTriple, CodeGenOpts, LangOpts, PB);
+  addSanitizers(TM.get(), TargetTriple, CodeGenOpts, LangOpts, PB);
   addKCFIPass(TargetTriple, LangOpts, PB);
 }
 
@@ -986,8 +986,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
 if (std::optional Options =
 getInstrProfOptions(CodeGenOpts, LangOpts))
   PB.registerPipelineStartEPCallback(
-  [Options](ModulePassManager , OptimizationLevel Level) {
-MPM.addPass(InstrProfilingLoweringPass(*Options, false));
+  [this, Options](ModulePassManager , OptimizationLevel Level) {
+MPM.addPass(InstrProfilingLoweringPass(TM.get(), *Options, false));
   });
 
 // TODO: Consider passing the MemoryProfileOutput to the pass builder via
diff --git a/llvm/include/llvm/Transforms/Instrumentation.h 
b/llvm/include/llvm/Transforms/Instrumentation.h
index ea97ab2562a5b0..a5866445529bfe 100644
--- a/llvm/include/llvm/Transforms/Instrumentation.h
+++ b/llvm/include/llvm/Transforms/Instrumentation.h
@@ -27,6 +27,7 @@
 namespace llvm {
 
 class Triple;
+class TargetMachine;
 class OptimizationRemarkEmitter;
 class Comdat;
 class CallBase;
@@ -52,8 +53,9 @@ Comdat *getOrCreateFunctionComdat(Function , Triple );
 // Place global in a large section for x86-64 ELF binaries to mitigate
 // relocation overflow pressure. This can be be used for metadata globals that
 // aren't directly accessed by code, which has no performance impact.
-void setGlobalVariableLargeSection(const Triple ,
-   GlobalVariable );
+void setGlobalVariableLargeSection(GlobalVariable ,
+   const Triple ,
+   const TargetMachine *TM);
 
 // Insert GCOV profiling instrumentation
 struct GCOVOptions {
diff --git a/llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h 
b/llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
index 6dfdfb729cf502..ae5eae604a245e 100644
--- a/llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
+++ 

[clang] [llvm] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)

2023-12-14 Thread Fangrui Song via cfe-commits

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/75542
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)

2023-12-14 Thread Paul Kirth via cfe-commits


@@ -0,0 +1,35 @@
+;; Check that certain globals are in large sections under x86-64 large code 
model (but not in other arches).
+; RUN: opt %s -mtriple=x86_64-unknown-linux -passes=instrprof -S | FileCheck %s

ilovepi wrote:

The comment makes it sound like this should have a RUN line for other arches. 
Was that intentional or copy paste from the other tests?

https://github.com/llvm/llvm-project/pull/75542
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits