[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi created
https://github.com/llvm/llvm-project/pull/72180
https://github.com/llvm/llvm-project/issues/70703 pointed out that cloning LLVM
modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels (see #55991
and #47769). Since this can lead to miscompilation, we can avoid cloning the
LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module or run
an input pipeline over it. Further, it make FatLTO always perform UnifiedLTO,
so we can still defer the Thin/Full LTO decision to link-time. Lastly, it
removes dead/obsolete code related to now defunct options that do not work with
the EmbedBitcodePass implementation any longer.
>From 061650962e36a9826de55770a51815ebd5a42fc9 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 10064
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6f07f561df390cfd1b0f36d510110f4daef0bc54 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.full.no
[clang] [clang][fatlto] Don't set ThinLTO module flag with FatLTO (PR #75079)
https://github.com/ilovepi created
https://github.com/llvm/llvm-project/pull/75079
Since FatLTO now uses the UnifiedLTO pipeline, we should not set the ThinLTO
module flag to true, since it may cause an assertion failure. See
https://github.com/llvm/llvm-project/issues/70703 for context.
>From 14805bacc7adce5ca41b6f064c219cd4a7c1fe89 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 11 Dec 2023 09:38:44 -0800
Subject: [PATCH] [clang][fatlto] Don't set ThinLTO module flag with FatLTO
Since FatLTO now uses the UnifiedLTO pipeline, we should not set
the ThinLTO module flag to true, since it may cause an assertion
failure. See https://github.com/llvm/llvm-project/issues/70703 for
context.
---
clang/lib/CodeGen/BackendUtil.cpp| 5 +
clang/test/CodeGen/fat-lto-objects.c | 3 +--
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index 77455c075cab0d..5ffda8117db1b3 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -1063,11 +1063,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
}
if (CodeGenOpts.FatLTO) {
-// Set module flags, like EnableSplitLTOUnit and UnifiedLTO, since FatLTO
+// Set the EnableSplitLTOUnit and UnifiedLTO module flags, since FatLTO
// uses a different action than Backend_EmitBC or Backend_EmitLL.
-if (!TheModule->getModuleFlag("ThinLTO"))
- TheModule->addModuleFlag(llvm::Module::Error, "ThinLTO",
- uint32_t(CodeGenOpts.PrepareForThinLTO));
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 95207e77c244cc..5c8ad1fd93c4b3 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -35,8 +35,7 @@
// SPLIT: ![[#]] = !{i32 1, !"EnableSplitLTOUnit", i32 1}
// NOSPLIT: ![[#]] = !{i32 1, !"EnableSplitLTOUnit", i32 0}
-/// Check that the ThinLTO metadata is set true for both full and thin LTO,
since FatLTO is based on UnifiedLTO.
-// FULL: ![[#]] = !{i32 1, !"ThinLTO", i32 1}
+// FULL-NOT: ![[#]] = !{i32 1, !"ThinLTO", i32 0}
// THIN-NOT: ![[#]] = !{i32 1, !"ThinLTO", i32 0}
/// FatLTO always uses UnifiedLTO. It's an error if they aren't set together
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] Reland "[clang][DebugInfo] Emit global variable definitions for static data members with constant initializers" (PR #71780)
ilovepi wrote: Hi, we're seeing some breakages, similar to the above in our debugger tests with this patch. A failing bot can be found here: https://luci-milo.appspot.com/ui/p/fuchsia/builders/ci/clang_toolchain.ci.core.x64-debug/b8764552260903625809/overview You can find a fuller discussion in our bugtracker: https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=136182. The problem in our test is that the `DW_AT_const_value`, no longer seems to be in the expected place, similar to @dyung's issue above. Is there an ETA on when your fix will land? If it won't be soon, would you mind reverting until you can address this issue? https://github.com/llvm/llvm-project/pull/71780 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] Reland "[clang][DebugInfo] Emit global variable definitions for static data members with constant initializers" (PR #71780)
ilovepi wrote: Fantastic! https://github.com/llvm/llvm-project/pull/71780 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] Reland "[clang][DebugInfo] Emit global variable definitions for static data members with constant initializers" (PR #71780)
ilovepi wrote: I'm unclear on the specifics of the check, but it's probably something we can adjust if that is the long-term solution. CC @petrhosek Since he was interested in getting this resolved soon. https://github.com/llvm/llvm-project/pull/71780 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][DebugInfo] Attach DW_AT_const_value to static data-member definitions if available (PR #72730)
ilovepi wrote: This looks great, thanks for keeping me in the loop. :) https://github.com/llvm/llvm-project/pull/72730 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake] Include opt-viewer in Fuchsia toolchain (PR #75296)
https://github.com/ilovepi approved this pull request. https://github.com/llvm/llvm-project/pull/75296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake] Include opt-viewer in Fuchsia toolchain (PR #75296)
https://github.com/ilovepi closed https://github.com/llvm/llvm-project/pull/75296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [flang] [mlir] [lldb] [compiler-rt] [llvm] [Profile] Add binary profile correlation for code coverage. (PR #69493)
ilovepi wrote: I think our Linux CI is seeing failures related to this patch: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-arm64/b8761705440671462977/overview Profile-aarch64 :: instrprof-binary-correlate.c is failing on that bot for both x86_64 and arm64. https://github.com/llvm/llvm-project/pull/69493 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [flang] [mlir] [lldb] [compiler-rt] [llvm] [Profile] Add binary profile correlation for code coverage. (PR #69493)
ilovepi wrote: Test output: ``` TEST 'Profile-aarch64 :: instrprof-binary-correlate.c' FAILED Exit Code: 1 Command Output (stdout): -- Binary files /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.profdata and /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp-1.profdata differ -- Command Output (stderr): -- RUN: at line 3: /b/s/w/ir/x/w/llvm_build/./bin/clang-Wthread-safety -Wthread-safety-reference -Wthread-safety-beta -ldl -o /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal -fprofile-instr-generate -fcoverage-mapping /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/profile/Inputs/instrprof-debug-info-correlate-main.cpp /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/profile/Inputs/instrprof-debug-info-correlate-foo.cpp + /b/s/w/ir/x/w/llvm_build/./bin/clang -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta -ldl -o /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal -fprofile-instr-generate -fcoverage-mapping /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/profile/Inputs/instrprof-debug-info-correlate-main.cpp /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/profile/Inputs/instrprof-debug-info-correlate-foo.cpp RUN: at line 4: env LLVM_PROFILE_FILE=/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.profraw /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal + env LLVM_PROFILE_FILE=/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.profraw /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal RUN: at line 5: llvm-profdata merge -o /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.profdata /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.profraw + llvm-profdata merge -o /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.profdata /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.profraw RUN: at line 6: llvm-cov report --instr-profile=/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.profdata /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal > /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.report + llvm-cov report --instr-profile=/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.profdata /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal RUN: at line 7: llvm-cov show --instr-profile=/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.profdata /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal > /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.show + llvm-cov show --instr-profile=/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal.profdata /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins/compiler-rt/test/profile/Profile-aarch64/Output/instrprof-binary-correlate.c.tmp.normal RUN: at line 10: /b/s/w/ir/x/w/llvm_bui
[clang] [clang-tools-extra] [flang] [mlir] [lldb] [compiler-rt] [llvm] [Profile] Add binary profile correlation for code coverage. (PR #69493)
ilovepi wrote: Seems like a mismatch on the diff, so maybe the check is too stringent. If this will take a while to fix, would you mind reverting until it can be addressed? https://github.com/llvm/llvm-project/pull/69493 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lldb] [mlir] [clang-tools-extra] [clang] [flang] [llvm] [compiler-rt] [Profile] Add binary profile correlation for code coverage. (PR #69493)
ilovepi wrote: Our next cI run should finish in about 25 minutes, so we'll find out soon. https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8761696932167687409/overview https://github.com/llvm/llvm-project/pull/69493 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[mlir] [clang-tools-extra] [lldb] [llvm] [flang] [clang] [compiler-rt] [Profile] Add binary profile correlation for code coverage. (PR #69493)
ilovepi wrote: Well, seems like someone broke ToT w/ a compiler error. I'll let you know if the forward fix fails to address the issue. https://github.com/llvm/llvm-project/pull/69493 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [flang] [clang-tools-extra] [mlir] [compiler-rt] [lldb] [clang] [Profile] Add binary profile correlation for code coverage. (PR #69493)
ilovepi wrote: Indeed. Thank you! https://github.com/llvm/llvm-project/pull/69493 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)
ilovepi wrote: > Actually I'm going to go down the `Module::getCodeModel()` route. Right now I > think frontends adding module metadata for the code model is probably not > common, but we should aim for that. And this will in the short term still > work for Fuchsia without breaking API for other frontends. It just makes > updating tests more annoying since now they have to ingest IR with the proper > code model metadata. I actually thought it was already available in the Module, and was surprised you had to pass TargetMachine around like that. If I understand where you're going with this, then I think that sounds like a really nice improvement. 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
[llvm] [clang] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)
ilovepi wrote: well I guess I should say I thought it would be reliable rather than available, but I see why it wouldn't be. 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
[llvm] [clang] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)
https://github.com/ilovepi edited 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
[llvm] [clang] [Instrumentation][X86] Limit setting large section flag to medium/large code models (PR #75542)
https://github.com/ilovepi approved this pull request. LGTM modulo one small comment in the test. Thanks for getting this done so quickly. 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)
@@ -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
[clang-tools-extra] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66915
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 1/4] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a signed
[clang-tools-extra] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66915
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 1/5] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a signed
[clang-tools-extra] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -3107,6 +3136,41 @@ void RISCVAsmParser::emitLoadTLSGDAddress(MCInst &Inst,
SMLoc IDLoc,
RISCV::ADDI, IDLoc, Out);
}
+void RISCVAsmParser::emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc,
+MCStreamer &Out) {
+ // The load TLS GD address pseudo-instruction "la.tlsdesc" is used in
+ // global-dynamic TLS model addressing of global symbols:
+ // la.tlsdesc rdest, symbol
+ // expands to
+ // TmpLabel: AUIPC rdest, %tlsdesc_hi(symbol)
+ // ADDI rdest, rdest, %pcrel_lo(TmpLabel)
ilovepi wrote:
I've gone ahead and dropped the AsmParser bits for `la.tlsdesc`, since we won't
output that into assembly. Le tme now if you're happy with that change, or
you'd prefer a different solution.
https://github.com/llvm/llvm-project/pull/66915
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -3246,6 +3310,18 @@ bool RISCVAsmParser::checkPseudoAddTPRel(MCInst &Inst, return false; } +bool RISCVAsmParser::checkPseudoTLSDESCCall(MCInst &Inst, ilovepi wrote: done https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang-tools-extra] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -6843,6 +6845,24 @@ SDValue RISCVTargetLowering::getDynamicTLSAddr(GlobalAddressSDNode *N, return LowerCallTo(CLI).first; } +SDValue +RISCVTargetLowering::getGeneralDynamicTLSDescAddr(GlobalAddressSDNode *N, ilovepi wrote: Well, AArch64 handles lowering for llvm's general-dynamic and local-dynamic cases differently. I was trying to make it clear here that we're not trying to do anything fancy like elide loads of the `__MODULE_BASE__` for multiple accesses. I'm not convinced we want to do that in RISC-V, so it's probably fine to rename this. Maybe `getTLSDescAddr` is good enough? at least until we decide that we want to optimize them differently. https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang-tools-extra] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66915
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 1/7] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a signed
[llvm] [clang-tools-extra] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -6843,6 +6845,24 @@ SDValue RISCVTargetLowering::getDynamicTLSAddr(GlobalAddressSDNode *N, return LowerCallTo(CLI).first; } +SDValue +RISCVTargetLowering::getGeneralDynamicTLSDescAddr(GlobalAddressSDNode *N, ilovepi wrote: done. https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][fatlto] Don't set ThinLTO module flag with FatLTO (PR #75079)
https://github.com/ilovepi closed https://github.com/llvm/llvm-project/pull/75079 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline( // Only enable CGProfilePass when using integrated assembler, since // non-integrated assemblers don't recognize .cgprofile section. PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS; - PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO; + PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO; ilovepi wrote: Yeah, this is probably redundant since I made that change earlier in the driver. The assert is also a good suggestion, so I'll update this patch to do that too. For the module flag, I'll need to check, since I think that it won't be set otherwise, but maybe I can factor it out into a common block. https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline( // Only enable CGProfilePass when using integrated assembler, since // non-integrated assemblers don't recognize .cgprofile section. PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS; - PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO; + PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO; ilovepi wrote: Ah, I remember why I did this now. The code in `Driver/Toolchains/Clang.cpp` set things nicely from `clang`, but didn't handle `cc1`. I believe that is because these are both CodeGenOpts defined in the TableGen files. This feels like it ought to be simple, but the driver bits have never been that intuitive to me. I *think* if I wanted to handle this directly, then I'd need to supply the implementation for both FatLTO and UnifiedLTO instead of relying on the TableGened impl, which seems worse than the current version. Do you have any thoughts on a nicer way to avoid the redundant code here? Maybe we don't need the changes to `Driver/Toolchains/Clang.cpp`? https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline( // Only enable CGProfilePass when using integrated assembler, since // non-integrated assemblers don't recognize .cgprofile section. PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS; - PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO; + PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO; ilovepi wrote: Exactly, but that doesn't change the behavior for cc1 invocations themselves ... or is that the expected behavior? https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi edited https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline( // Only enable CGProfilePass when using integrated assembler, since // non-integrated assemblers don't recognize .cgprofile section. PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS; - PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO; + PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO; ilovepi wrote: Thanks for the clarification. In that case I guess I can go back to my original plan and just update the test invocations accordingly. https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6f07f561df390cfd1b0f36d510110f4daef0bc54 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH 1/2] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.ful
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline( // Only enable CGProfilePass when using integrated assembler, since // non-integrated assemblers don't recognize .cgprofile section. PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS; - PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO; + PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO; ilovepi wrote: Thank you! that was exactly the kind of place I was hoping to find. https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6f07f561df390cfd1b0f36d510110f4daef0bc54 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH 1/3] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.ful
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -1861,6 +1861,13 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions
&Opts, ArgList &Args,
if (Args.hasArg(OPT_funified_lto))
Opts.PrepareForThinLTO = true;
}
+ if (Arg *A = Args.getLastArg(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects)) {
+if (!Args.hasArg(OPT_funified_lto))
+ Diags.Report(diag::err_drv_incompatible_options)
ilovepi wrote:
Thanks for the suggestion. I think the new version handles that now.
https://github.com/llvm/llvm-project/pull/72180
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -1530,14 +1530,11 @@
PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
}
ModulePassManager
-PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level, bool ThinLTO,
-bool EmitSummary) {
+PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level) {
ModulePassManager MPM;
- MPM.addPass(EmbedBitcodePass(ThinLTO, EmitSummary,
- ThinLTO
- ? buildThinLTOPreLinkDefaultPipeline(Level)
- : buildLTOPreLinkDefaultPipeline(Level)));
- MPM.addPass(buildPerModuleDefaultPipeline(Level));
+ MPM.addPass(buildThinLTOPreLinkDefaultPipeline(Level));
+ MPM.addPass(EmbedBitcodePass());
+ MPM.addPass(buildThinLTODefaultPipeline(Level, /*ImportSummary=*/nullptr));
ilovepi wrote:
Yeah, I'm not super happy with it, but based on the discussion from the initial
patches, we'd need something that is close to make sure that all the various
issues from optional passes like profiling, etc. were handled, correct?
Otherwise, I guess we can sub in ModuleOptimization here? @teresajohnson do you
think that would run into any trouble based on your concerns in
https://reviews.llvm.org/D146776#4302238 and the subsequent discussion.
https://github.com/llvm/llvm-project/pull/72180
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6f07f561df390cfd1b0f36d510110f4daef0bc54 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH 1/4] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.ful
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -29,30 +29,31 @@ Overview Within LLVM, FatLTO is supported by choosing the ``FatLTODefaultPipeline``. This pipeline will: -#) Clone the IR module. -#) Run the pre-link (Thin)LTO pipeline using the cloned module. +#) Run the pre-link UnifiedLTO pipeline on the current module. #) Embed the pre-link bitcode in a special ``.llvm.lto`` section. -#) Optimize the unmodified copy of the module using the normal compilation pipeline. +#) Finish optimizing the module using the post-link ThinLTO pipeline. #) Emit the object file, including the new ``.llvm.lto`` section. .. NOTE - At the time of writing, we conservatively run independent pipelines to - generate the bitcode section and the object code, which happen to be - identical to those used outside of FatLTO. This results in compiled - artifacts that are identical to those produced by the default and (Thin)LTO - pipelines. However, this is not a guarantee, and we reserve the right to - change this at any time. Explicitly, users should not rely on the produced - bitcode or object code to mach their non-LTO counterparts precisely. They - will exhibit similar performance characteristics, but may not be bit-for-bit - the same. + Previously, we conservatively ran independent pipelines on separate copies + of the LLVM module to generate the bitcode section and the object code, + which happen to be identical to those used outside of FatLTO. While that + resulted in compiled artifacts that were identical to those produced by the + default and (Thin)LTO pipelines, module cloning led to some cases of + miscompilation, and we have moved away from trying to keep bitcode + generation and optimization completely disjoint. + + Bit-for-bit compatibility is not (and never was) a guarantee, and we reserve + the right to change this at any time. Explicitly, users should not rely on + the produced bitcode or object code to mach their non-LTO counterparts ilovepi wrote: Ah, good catch. Thank you! https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -1530,14 +1530,11 @@
PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
}
ModulePassManager
-PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level, bool ThinLTO,
-bool EmitSummary) {
+PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level) {
ModulePassManager MPM;
- MPM.addPass(EmbedBitcodePass(ThinLTO, EmitSummary,
- ThinLTO
- ? buildThinLTOPreLinkDefaultPipeline(Level)
- : buildLTOPreLinkDefaultPipeline(Level)));
- MPM.addPass(buildPerModuleDefaultPipeline(Level));
+ MPM.addPass(buildThinLTOPreLinkDefaultPipeline(Level));
+ MPM.addPass(EmbedBitcodePass());
+ MPM.addPass(buildThinLTODefaultPipeline(Level, /*ImportSummary=*/nullptr));
ilovepi wrote:
oh, that's fantastic. Let me give that a try , since it seems better to just
handle this right now instead of patching it after the fact.
https://github.com/llvm/llvm-project/pull/72180
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -1530,14 +1530,11 @@
PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
}
ModulePassManager
-PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level, bool ThinLTO,
-bool EmitSummary) {
+PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level) {
ModulePassManager MPM;
- MPM.addPass(EmbedBitcodePass(ThinLTO, EmitSummary,
- ThinLTO
- ? buildThinLTOPreLinkDefaultPipeline(Level)
- : buildLTOPreLinkDefaultPipeline(Level)));
- MPM.addPass(buildPerModuleDefaultPipeline(Level));
+ MPM.addPass(buildThinLTOPreLinkDefaultPipeline(Level));
+ MPM.addPass(EmbedBitcodePass());
+ MPM.addPass(buildThinLTODefaultPipeline(Level, /*ImportSummary=*/nullptr));
ilovepi wrote:
Running some quick checks, that seems to work well, and non-LTO codegen looks
more or less as expected (at least on a few test programs). I probably won't be
able to benchmark this on compile times until later today or more likely
tomorrow, though.
https://github.com/llvm/llvm-project/pull/72180
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6f07f561df390cfd1b0f36d510110f4daef0bc54 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH 1/5] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.ful
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6f07f561df390cfd1b0f36d510110f4daef0bc54 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH 1/6] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.ful
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -1530,14 +1530,11 @@
PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
}
ModulePassManager
-PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level, bool ThinLTO,
-bool EmitSummary) {
+PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level) {
ModulePassManager MPM;
- MPM.addPass(EmbedBitcodePass(ThinLTO, EmitSummary,
- ThinLTO
- ? buildThinLTOPreLinkDefaultPipeline(Level)
- : buildLTOPreLinkDefaultPipeline(Level)));
- MPM.addPass(buildPerModuleDefaultPipeline(Level));
+ MPM.addPass(buildThinLTOPreLinkDefaultPipeline(Level));
+ MPM.addPass(EmbedBitcodePass());
+ MPM.addPass(buildThinLTODefaultPipeline(Level, /*ImportSummary=*/nullptr));
ilovepi wrote:
I think compile time was the big concern, otherwise, I think using the
ThinLTODefaultPipeline would be fine.
https://github.com/llvm/llvm-project/pull/72180
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
ilovepi wrote: @nikic are there any other changes you'd like to see? otherwise, I plan to rebase and land this later today. https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6f07f561df390cfd1b0f36d510110f4daef0bc54 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH 1/7] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 8 +
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 99 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index a7a47d17723cb73..4114860545ade1b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3b98c7ae6e6ec66..f4cd9cbc5eccdec 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4845,7 +4845,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.ful
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
@@ -29,34 +29,42 @@ Overview Within LLVM, FatLTO is supported by choosing the ``FatLTODefaultPipeline``. This pipeline will: -#) Clone the IR module. -#) Run the pre-link (Thin)LTO pipeline using the cloned module. +#) Run the pre-link UnifiedLTO pipeline on the current module. #) Embed the pre-link bitcode in a special ``.llvm.lto`` section. -#) Optimize the unmodified copy of the module using the normal compilation pipeline. +#) Finish optimizing the module using the post-link ThinLTO pipeline. #) Emit the object file, including the new ``.llvm.lto`` section. .. NOTE - At the time of writing, we conservatively run independent pipelines to - generate the bitcode section and the object code, which happen to be - identical to those used outside of FatLTO. This results in compiled - artifacts that are identical to those produced by the default and (Thin)LTO - pipelines. However, this is not a guarantee, and we reserve the right to - change this at any time. Explicitly, users should not rely on the produced - bitcode or object code to mach their non-LTO counterparts precisely. They - will exhibit similar performance characteristics, but may not be bit-for-bit - the same. + Previously, we conservatively ran independent pipelines on separate copies + of the LLVM module to generate the bitcode section and the object code, + which happen to be identical to those used outside of FatLTO. While that + resulted in compiled artifacts that were identical to those produced by the + default and (Thin)LTO pipelines, module cloning led to some cases of + miscompilation, and we have moved away from trying to keep bitcode + generation and optimization completely disjoint. + + Bit-for-bit compatibility is not (and never was) a guarantee, and we reserve + the right to change this at any time. Explicitly, users should not rely on + the produced bitcode or object code to match their non-LTO counterparts + precisely. They will exhibit similar performance characteristics, but may + not be bit-for-bit the same. Internally, the ``.llvm.lto`` section is created by running the -``EmbedBitcodePass`` at the start of the ``PerModuleDefaultPipeline``. This -pass is responsible for cloning and optimizing the module with the appropriate -LTO pipeline and emitting the ``.llvm.lto`` section. Afterwards, the -``PerModuleDefaultPipeline`` runs normally and the compiler can emit the fat -object file. +``EmbedBitcodePass`` after the ``ThinLTOPreLinkDefaultPipeline``. This pass is +responsible for emitting the ``.llvm.lto`` section. Afterwards, the +``ThinLTODefaultPipeline`` runs and the compiler can emit the fat object file. Limitations === +Sample-Based PGO + + +If FatLTO is used together with SamplePGO (as opposed to normal +instrumentation-based PGO), some profile-based optimizations will only be +applied when linking with LTO. ilovepi wrote: Thanks for pointing that out. I forgot that I didn't need this comment after updating the SampleProfile case. https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/72180
>From 6d971446fac3c65b1e7d48a7c9277b35133460ff Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Mon, 13 Nov 2023 23:54:51 +
Subject: [PATCH 1/8] [clang][llvm][fatlto] Avoid cloning modules in FatLTO
https://github.com/llvm/llvm-project/issues/70703 pointed out that
cloning LLVM modules could lead to miscompiles when using FatLTO.
This is due to an existing issue when cloning modules with labels
(see #55991 and #47769). Since this can lead to miscompilation,
we can avoid cloning the LLVM modules, which was desirable anyway.
This patch modifies the EmbedBitcodePass to no longer clone the module
or run an input pipeline over it. Further, it make FatLTO always perform
UnifiedLTO, so we can still defer the Thin/Full LTO decision to
link-time. Lastly, it removes dead/obsolete code related to now defunct
options that do not work with the EmbedBitcodePass implementation any
longer.
---
clang/lib/CodeGen/BackendUtil.cpp | 9 +++--
clang/lib/Driver/ToolChains/Clang.cpp | 4 ++-
clang/test/CodeGen/fat-lto-objects.c | 10 +++---
llvm/docs/FatLTO.rst | 35 ++-
llvm/include/llvm/Passes/PassBuilder.h| 3 +-
.../llvm/Transforms/IPO/EmbedBitcodePass.h| 17 +
llvm/lib/Passes/PassBuilder.cpp | 20 ---
llvm/lib/Passes/PassBuilderPipelines.cpp | 11 +++---
llvm/lib/Passes/PassRegistry.def | 5 +--
llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp | 16 +
llvm/test/CodeGen/X86/fat-lto-section.ll | 2 +-
llvm/test/Transforms/EmbedBitcode/embed.ll| 3 --
12 files changed, 39 insertions(+), 96 deletions(-)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index f01a6514f6effb0..724b0fc1d7c0a5d 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -810,7 +810,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
// Only enable CGProfilePass when using integrated assembler, since
// non-integrated assemblers don't recognize .cgprofile section.
PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
- PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO;
+ PTO.UnifiedLTO = CodeGenOpts.UnifiedLTO || CodeGenOpts.FatLTO;
LoopAnalysisManager LAM;
FunctionAnalysisManager FAM;
@@ -996,9 +996,7 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM.addPass(PB.buildFatLTODefaultPipeline(
- Level, PrepareForThinLTO,
- PrepareForThinLTO || shouldEmitRegularLTOSummary()));
+ MPM.addPass(PB.buildFatLTODefaultPipeline(Level));
} else if (PrepareForThinLTO) {
MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
@@ -1073,7 +1071,8 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
TheModule->addModuleFlag(llvm::Module::Error, "EnableSplitLTOUnit",
uint32_t(CodeGenOpts.EnableSplitLTOUnit));
-if (CodeGenOpts.UnifiedLTO && !TheModule->getModuleFlag("UnifiedLTO"))
+// FatLTO always means UnifiedLTO
+if (!TheModule->getModuleFlag("UnifiedLTO"))
TheModule->addModuleFlag(llvm::Module::Error, "UnifiedLTO", uint32_t(1));
}
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3c8df8a9037d695..b1ce95be38f88d5 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4862,7 +4862,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
bool UnifiedLTO = false;
if (IsUsingLTO) {
UnifiedLTO = Args.hasFlag(options::OPT_funified_lto,
- options::OPT_fno_unified_lto, Triple.isPS());
+ options::OPT_fno_unified_lto, Triple.isPS()) ||
+ Args.hasFlag(options::OPT_ffat_lto_objects,
+ options::OPT_fno_fat_lto_objects, false);
if (UnifiedLTO)
CmdArgs.push_back("-funified-lto");
}
diff --git a/clang/test/CodeGen/fat-lto-objects.c
b/clang/test/CodeGen/fat-lto-objects.c
index 2c3a4ef9c615529..6085762fa5a2467 100644
--- a/clang/test/CodeGen/fat-lto-objects.c
+++ b/clang/test/CodeGen/fat-lto-objects.c
@@ -9,22 +9,22 @@
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -fsplit-lto-unit -emit-obj < %s -o %t.full.split.o
// RUN: llvm-readelf -S %t.full.split.o | FileCheck %s --check-prefixes=ELF
// RUN: llvm-objcopy --dump-section=.llvm.lto=%t.full.split.bc %t.full.split.o
-// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,NOUNIFIED
+// RUN: llvm-dis %t.full.split.bc -o - | FileCheck %s
--check-prefixes=FULL,SPLIT,UNIFIED
// RUN: %clang -cc1 -triple x86_64-unknown-linux-gnu -flto=full
-ffat-lto-objects -emit-obj < %s -o %t.full.
[clang] [llvm] [clang][llvm][fatlto] Avoid cloning modules in FatLTO (PR #72180)
https://github.com/ilovepi closed https://github.com/llvm/llvm-project/pull/72180 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [llvm] [clang] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66915
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 01/12] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a sign
[llvm] [clang-tools-extra] [clang] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -1722,6 +1722,35 @@ let hasSideEffects = 0, mayLoad = 0, mayStore = 0, Size = 8, isCodeGenOnly = 0, isAsmParserOnly = 1 in def PseudoLA_TLS_GD : Pseudo<(outs GPR:$dst), (ins bare_symbol:$src), [], "la.tls.gd", "$dst, $src">; +let hasSideEffects = 0, mayLoad = 1, mayStore = 0, Size = 32, isCodeGenOnly = 0, +isAsmParserOnly = 1 in ilovepi wrote: Ah, I think I missed this when I dropped the AsmParser bits. So, I *think* that means I want to set isAsmParserOnly=0, isCodeGenOnly=0, isPseudo=1, which I think is the case now. Is that the correct way to model a pseudo that is only for some internal state that shouldn't be emitted to assembly? That's my understanding from https://github.com/llvm-mirror/llvm/blob/2c4ca6832fa6b306ee6a7010bfb80a3f2596f824/include/llvm/Target/Target.td#L554 , at least, but I'm not sure if that is a correct interpretation or not. https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66915
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 01/14] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a sign
[clang-tools-extra] [clang] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -71,6 +71,18 @@ enum Fixups {
// Used to generate an R_RISCV_ALIGN relocation, which indicates the linker
// should fixup the alignment after linker relaxation.
fixup_riscv_align,
+ // 20-bit fixup corresponding to %tlsdesc_hi(foo) for instructions like
+ // auipc
+ fixup_riscv_tlsdesc_hi20,
+ // 12-bit fixup corresponding to %tlsdesc_load_lo(foo) for instructions like
+ // addi
ilovepi wrote:
Yes, I've fixed it now to use `lw`, but maybe it should just read `... for load
instructions` instead? WDYT?
https://github.com/llvm/llvm-project/pull/66915
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -597,7 +613,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
ilovepi wrote:
I think the tests added in RISCV/MC should cover this now. Please let me know
if I've missed one of the cases.
https://github.com/llvm/llvm-project/pull/66915
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -188,3 +188,8 @@ addi a2, ft0, 24 # CHECK: :[[@LINE]]:10: error: invalid operand for instruction # fence.tso accepts no operands fence.tso rw, rw # CHECK: :[[@LINE]]:11: error: invalid operand for instruction + +.Ltlsdesc_hi0: +jalr x5, 0(a1), %tlsdesc_hi(.Ltlsdesc_hi0) # CHECK: :[[@LINE]]:17: error: operand must be a symbol with %tlsdesc_call modifier +jalr x1, 0(a1), %tlsdesc_call(.Ltlsdesc_hi0) # CHECK: :[[@LINE]]:12: error: the output operand must be t0/x5 when using %tlsdesc_call modifier ilovepi wrote: You're right. I've added some that should address that i `rv32-tlsdesc-valid.s` and `rv64-tlsdesc-valid.s` https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66915
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 01/15] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a sign
[clang] [clang-tools-extra] [llvm] [lld] [RISC-V][LLD] Add Support for RISC-V TLSDESC Relocations (PR #66916)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66916
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 01/17] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a sign
[clang] [lldb] [libcxxabi] [lld] [flang] [llvm] [libc] [libcxx] [compiler-rt] [clang-tools-extra] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66915
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 01/15] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a sign
[clang] [lldb] [libcxxabi] [lld] [flang] [llvm] [libc] [libcxx] [compiler-rt] [clang-tools-extra] [RISC-V][LLD] Add Support for RISC-V TLSDESC Relocations (PR #66916)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/66916
>From ce9772dd519a62025cf545ded306bf40c75f2924 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 19 Sep 2023 20:53:54 +
Subject: [PATCH 01/17] [RISCV] Support Global Dynamic TLSDESC in the RISC-V
backend
This patch adds basic TLSDESC support for the global dynamic case in the
RISC-V backend by adding new relocation types for TLSDESC, as prescribed
in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373.
We also add a new pseudo instruction to simplify code generation.
Possible improvements for the local dynamic case will be addressed in separate
patches.
The current implementation is only enabled when passing the
-riscv-enable-tlsdesc flag.
---
.../llvm/BinaryFormat/ELFRelocs/RISCV.def | 4 +
.../Target/RISCV/AsmParser/RISCVAsmParser.cpp | 97 +--
.../RISCV/MCTargetDesc/RISCVAsmBackend.cpp| 9 ++
.../Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | 6 +-
.../MCTargetDesc/RISCVELFObjectWriter.cpp | 15 +++
.../RISCV/MCTargetDesc/RISCVFixupKinds.h | 12 +++
.../RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp | 46 +
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp | 18
.../Target/RISCV/MCTargetDesc/RISCVMCExpr.h | 4 +
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 12 +++
.../Target/RISCV/RISCVExpandPseudoInsts.cpp | 53 ++
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 23 -
llvm/lib/Target/RISCV/RISCVISelLowering.h | 3 +
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp | 6 +-
llvm/lib/Target/RISCV/RISCVInstrInfo.td | 36 +++
llvm/lib/Target/RISCV/RISCVTargetMachine.cpp | 4 +
llvm/test/CodeGen/RISCV/tls-models.ll | 96 ++
17 files changed, 432 insertions(+), 12 deletions(-)
diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
index 9a126df0153119..94420395fa0fad 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def
@@ -55,3 +55,7 @@ ELF_RELOC(R_RISCV_SET32, 56)
ELF_RELOC(R_RISCV_32_PCREL, 57)
ELF_RELOC(R_RISCV_IRELATIVE, 58)
ELF_RELOC(R_RISCV_PLT32, 59)
+ELF_RELOC(R_RISCV_TLSDESC_HI20, 62)
+ELF_RELOC(R_RISCV_TLSDESC_LOAD_LO12, 63)
+ELF_RELOC(R_RISCV_TLSDESC_ADD_LO12, 64)
+ELF_RELOC(R_RISCV_TLSDESC_CALL, 65)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 7d8d82e381313b..1303f5e85aeeb6 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -152,6 +152,7 @@ class RISCVAsmParser : public MCTargetAsmParser {
// Helper to emit pseudo instruction "la.tls.gd" used in global-dynamic TLS
// addressing.
void emitLoadTLSGDAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
+ void emitLoadTLSDescAddress(MCInst &Inst, SMLoc IDLoc, MCStreamer &Out);
// Helper to emit pseudo load/store instruction with a symbol.
void emitLoadStoreSymbol(MCInst &Inst, unsigned Opcode, SMLoc IDLoc,
@@ -170,6 +171,12 @@ class RISCVAsmParser : public MCTargetAsmParser {
// 'add' is an overloaded mnemonic.
bool checkPseudoAddTPRel(MCInst &Inst, OperandVector &Operands);
+ // Checks that a PseudoTLSDESCCall is using x5/t0 in its output operand.
+ // Enforcing this using a restricted register class for the output
+ // operand of PseudoTLSDESCCall results in a poor diagnostic due to the fact
+ // 'jalr' is an overloaded mnemonic.
+ bool checkPseudoTLSDESCCall(MCInst &Inst, OperandVector &Operands);
+
// Check instruction constraints.
bool validateInstruction(MCInst &Inst, OperandVector &Operands);
@@ -533,6 +540,16 @@ struct RISCVOperand final : public MCParsedAsmOperand {
VK == RISCVMCExpr::VK_RISCV_TPREL_ADD;
}
+ bool isTLSDESCCallSymbol() const {
+int64_t Imm;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+// Must be of 'immediate' type but not a constant.
+if (!isImm() || evaluateConstantImm(getImm(), Imm, VK))
+ return false;
+return RISCVAsmParser::classifySymbolRef(getImm(), VK) &&
+ VK == RISCVMCExpr::VK_RISCV_TLSDESC_CALL;
+ }
+
bool isCSRSystemRegister() const { return isSystemRegister(); }
bool isVTypeImm(unsigned N) const {
@@ -584,7 +601,10 @@ struct RISCVOperand final : public MCParsedAsmOperand {
if (!isImm())
return false;
bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
-if (VK == RISCVMCExpr::VK_RISCV_LO || VK == RISCVMCExpr::VK_RISCV_PCREL_LO)
+if (VK == RISCVMCExpr::VK_RISCV_LO ||
+VK == RISCVMCExpr::VK_RISCV_PCREL_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_LOAD_LO ||
+VK == RISCVMCExpr::VK_RISCV_TLSDESC_ADD_LO)
return true;
// Given only Imm, ensuring that the actually specified constant is either
// a sign
[clang] [llvm] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)
@@ -151,9 +155,10 @@ Usage To enable ShadowCallStack, just pass the ``-fsanitize=shadow-call-stack`` flag to both compile and link command lines. On aarch64, you also need to pass -``-ffixed-x18`` unless your target already reserves ``x18``. On RISC-V, ``x3`` -(``gp``) is always reserved. It is, however, important to disable GP relaxation -in the linker. This can be done with the ``--no-relax-gp`` flag in GNU ld. +``-ffixed-x18`` unless your target already reserves ``x18``. On RISC-V with software +shadow stack, ``x3`` (``gp``) is always reserved. It is, however, important to +disable GP relaxation in the linker. This can be done with the ``--no-relax-gp`` +flag in GNU ld. ilovepi wrote: We reserve `gp` even w/o SCS. The `--no-relax-gp` advice does only apply to the software SCS. Maybe something along these lines? ```suggestion ``-ffixed-x18`` unless your target already reserves ``x18``. No additional flags need to be passed on RISC-V because the software based shadow stack uses ``x3`` (``gp``), which is always reserved, and the hardware based shadow call stack uses a dedicated register, ``ssp``. However, it is important to disable GP relaxation in the linker when using the software based shadow call stack on RISC-V. This can be done with the ``--no-relax-gp`` flag in GNU ld, and is off by default in LLD. ``` https://github.com/llvm/llvm-project/pull/68075 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)
https://github.com/ilovepi edited https://github.com/llvm/llvm-project/pull/68075 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)
https://github.com/ilovepi commented: Should the driver issue an error when using `-mforced-sw-shadow-stack` w/o `Zicfiss`? As mentioned in-line, I'm not sure we can do that check, but it feels like it should be incompatible. https://github.com/llvm/llvm-project/pull/68075 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)
@@ -57,11 +57,14 @@ compiled application or the operating system. Integrating the runtime into the operating system should be preferred since otherwise all thread creation and destruction would need to be intercepted by the application. -The instrumentation makes use of the platform register ``x18`` on AArch64 and -``x3`` (``gp``) on RISC-V. For simplicity we will refer to this as the -``SCSReg``. On some platforms, ``SCSReg`` is reserved, and on others, it is -designated as a scratch register. This generally means that any code that may -run on the same thread as code compiled with ShadowCallStack must either target +The instrumentation makes use of the platform register ``x18`` on AArch64, +``x3`` (``gp``) on RISC-V with software shadow stack and ``ssp`` on RISC-V with +hardware shadow stack, which needs `Zicfiss`_ and ``-mno-forced-sw-shadow-stack`` +(default option). ``-mforced-sw-shadow-stack`` make risc-v backend generate +software shadow stack with `Zicfiss`_ when shadow stack enabled. ilovepi wrote: ```suggestion hardware shadow stack, which needs `Zicfiss`_. Note that with ``Zicfiss``_ the RISC-V backend will default to the hardware based shadow call stack. Users can force the RISC-V backend to generate the software shadow call stack with ``Zicfiss``_ by passing ``-mforced-sw-shadow-stack``. ``` Maybe this is easier to follow? Might also make sense to outline when `-mforced-sw-shadow-stack` is expected to work somewhere, e.g., it has no effect w/o `Zicfiss``. TBH, in that case, the driver should probably issue an error, since its incompatible w/o the feature, but I'm not sure if we can do that check in the frontend or not. https://github.com/llvm/llvm-project/pull/68075 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)
ilovepi wrote: The title should probably be changed to something like: `[RISCV] Add Zicfiss support to the shadow call stack implementation` The current title doesn't make much sense to me, but maybe I've misunderstood the intent? https://github.com/llvm/llvm-project/pull/68075 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxxabi] [flang] [libc] [clang] [lldb] [compiler-rt] [clang-tools-extra] [llvm] [libcxx] [lld] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -3,8 +3,8 @@ # Out of range immediates ## simm12 -flh ft1, -2049(a0) # CHECK: :[[@LINE]]:10: error: operand must be a symbol with %lo/%pcrel_lo/%tprel_lo modifier or an integer in the range [-2048, 2047] -fsh ft2, 2048(a1) # CHECK: :[[@LINE]]:10: error: operand must be a symbol with %lo/%pcrel_lo/%tprel_lo modifier or an integer in the range [-2048, 2047] +flh ft1, -2049(a0) # CHECK: :[[@LINE]]:10: error: operand must be a symbol with %lo/%pcrel_lo/%tprel_lo/%tlsdesc_load_lo modifier or an integer in the range [-2048, 2047] ilovepi wrote: done. https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] [libc] [compiler-rt] [clang] [flang] [lld] [libcxxabi] [clang-tools-extra] [lldb] [llvm] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -0,0 +1,44 @@ +# RUN: llvm-mc -filetype=obj -triple riscv32 < %s --defsym RV32=1 | llvm-objdump -d -M no-aliases - | FileCheck %s --check-prefixes=INST,RV32 +# RUN: llvm-mc -filetype=obj -triple riscv64 < %s | llvm-objdump -d -M no-aliases - | FileCheck %s --check-prefixes=INST,RV64 + +# RUN: not llvm-mc -triple riscv32 < %s --defsym RV32=1 --defsym ERR=1 2>&1 | FileCheck %s --check-prefixes=ERR +# RUN: not llvm-mc -triple riscv64 < %s --defsym ERR=1 2>&1 | FileCheck %s --check-prefixes=ERR + +start: # @start +# %bb.0:# %entry +.Ltlsdesc_hi0: + auipc a0, %tlsdesc_hi(a-4) + # INST: auipc a0, 0x0 + auipc a0, %tlsdesc_hi(unspecified) + # INST: auipc a0, 0x0 +.ifdef RV32 + lw a1, %tlsdesc_load_lo(.Ltlsdesc_hi0)(a0) + # RV32: lw a1, 0x0(a0) +.else + ld a1, %tlsdesc_load_lo(.Ltlsdesc_hi0)(a0) + #RV64: ld a1, 0x0(a0) +.endif + addia0, a0, %tlsdesc_add_lo(.Ltlsdesc_hi0) + # INST: addi a0, a0, 0x0 + jalrt0, 0(a1), %tlsdesc_call(.Ltlsdesc_hi0) + # INST: jalr t0, 0x0(a1) + add a0, a0, tp + # INST: add a0, a0, tp + ret + +## Check invalid usage +.ifdef ERR + auipc x1, %tlsdesc_call(foo) # ERR: :[[@LINE]]:12: error: operand must be a symbol with a %pcrel_hi/%got_pcrel_hi/%tls_ie_pcrel_hi/%tls_gd_pcrel_hi/%tlsdesc_hi modifier or an integer in the range ilovepi wrote: Thanks. done. https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [libc] [flang] [libcxxabi] [libcxx] [lld] [clang] [clang-tools-extra] [compiler-rt] [lldb] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
@@ -71,6 +71,18 @@ enum Fixups {
// Used to generate an R_RISCV_ALIGN relocation, which indicates the linker
// should fixup the alignment after linker relaxation.
fixup_riscv_align,
+ // 20-bit fixup corresponding to %tlsdesc_hi(foo) for instructions like
+ // auipc
+ fixup_riscv_tlsdesc_hi20,
ilovepi wrote:
I've adjusted the comments per your suggestion, but could you elaborate more on
what you're thinking w.r.t. `MCFixupKind(FirstLiteralRelocationKind +
ELF::R_RISCV_TLSDESC_CALL)`?
https://github.com/llvm/llvm-project/pull/66915
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxxabi] [lld] [libcxx] [clang-tools-extra] [libc] [flang] [compiler-rt] [lldb] [clang] [llvm] [RISC-V][LLD] Add Support for RISC-V TLSDESC Relocations (PR #66916)
ilovepi wrote: > The base branch can be edited if you click "Edit" near the title, which will > help reveal the lld side changes... hmm, I was hoping that would work, but the base branch is in my fork. I think to make it work correctly I'd have to be using the "user" branches in the main repository. Maybe its better to re-open both of them using `spr`? That still seems bad, but it will probably make everyone a bit happier. I'll look into this a bit more, because I agree, its very hard to understand what is intended to be reviewed here vs what's been included from the base patch. https://github.com/llvm/llvm-project/pull/66916 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] [libc] [clang] [lldb] [llvm] [libcxxabi] [clang-tools-extra] [compiler-rt] [flang] [lld] [RISC-V][LLD] Add Support for RISC-V TLSDESC Relocations (PR #66916)
ilovepi wrote: @MaskRay , do you think this is worth abandoning in favor of https://github.com/llvm/llvm-project/pull/77516? If so, I guess I'd also need to abandon https://github.com/llvm/llvm-project/pull/66915, which is unfortunate. https://github.com/llvm/llvm-project/pull/66916 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] [libc] [lldb] [lld] [llvm] [libcxxabi] [clang-tools-extra] [compiler-rt] [flang] [clang] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
ilovepi wrote: @topperc @MaskRay , do either of you have strong feelings about abandoning this in favor of https://github.com/llvm/llvm-project/pull/77515? That PR was made w/ `spr` and should be a bit easier to understand/review (since it won't have merge or fixup commits) and will make the LLD side changes easier to stack. https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [libc] [compiler-rt] [lld] [llvm] [libcxxabi] [lldb] [clang] [libcxx] [clang-tools-extra] [RISC-V][LLD] Add Support for RISC-V TLSDESC Relocations (PR #66916)
ilovepi wrote: sounds good. I'll go ahead and close this in favor of https://github.com/llvm/llvm-project/pull/77516 then, and leave the LLVM PR alone. https://github.com/llvm/llvm-project/pull/66916 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lldb] [llvm] [libcxxabi] [clang] [clang-tools-extra] [lld] [libcxx] [compiler-rt] [libc] [flang] [RISC-V][LLD] Add Support for RISC-V TLSDESC Relocations (PR #66916)
https://github.com/ilovepi closed https://github.com/llvm/llvm-project/pull/66916 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lldb] [llvm] [libcxxabi] [clang] [clang-tools-extra] [lld] [libcxx] [compiler-rt] [libc] [flang] [RISCV] Support Global Dynamic TLSDESC in the RISC-V backend (PR #66915)
ilovepi wrote: As @MaskRay pointed out in #66916, there's a bit too much context in this review, so please just ignore my earlier question about moving to a stacked PR. https://github.com/llvm/llvm-project/pull/66915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] a427e18 - [docs][misexpect][NFC] Fix malformed table in docs
Author: Paul Kirth Date: 2022-03-29T00:14:07Z New Revision: a427e18896dee3cd00d5f565cfb9d7d2f26ebcec URL: https://github.com/llvm/llvm-project/commit/a427e18896dee3cd00d5f565cfb9d7d2f26ebcec DIFF: https://github.com/llvm/llvm-project/commit/a427e18896dee3cd00d5f565cfb9d7d2f26ebcec.diff LOG: [docs][misexpect][NFC] Fix malformed table in docs Reviewed By: abrachet Differential Revision: https://reviews.llvm.org/D122623 Added: Modified: clang/docs/MisExpect.rst llvm/docs/MisExpect.rst Removed: diff --git a/clang/docs/MisExpect.rst b/clang/docs/MisExpect.rst index c3c8e97cb050c..29eb1269b8982 100644 --- a/clang/docs/MisExpect.rst +++ b/clang/docs/MisExpect.rst @@ -64,7 +64,7 @@ Sampling. MisExpect Diagnostics are compatible with all Profiling formats. ++--+ | Profile Type | Description | ++==+ -| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang``| +| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang`` | ++--+ | IR | Profiling instrumentation added during by the LLVM backend | ++--+ diff --git a/llvm/docs/MisExpect.rst b/llvm/docs/MisExpect.rst index b4b6e2c5336dc..a9e6f8cc7006d 100644 --- a/llvm/docs/MisExpect.rst +++ b/llvm/docs/MisExpect.rst @@ -62,7 +62,7 @@ Sampling. MisExpect Diagnostics are compatible with all Profiling formats. ++--+ | Profile Type | Description | ++==+ -| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang``| +| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang`` | ++--+ | IR | Profiling instrumentation added during by the LLVM backend | ++--+ ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 6c77972 - Revert "[docs][misexpect][NFC] Fix malformed table in docs"
Author: Paul Kirth Date: 2022-03-29T06:19:53Z New Revision: 6c77972bac7ce125110ed2baea9919fb6866db39 URL: https://github.com/llvm/llvm-project/commit/6c77972bac7ce125110ed2baea9919fb6866db39 DIFF: https://github.com/llvm/llvm-project/commit/6c77972bac7ce125110ed2baea9919fb6866db39.diff LOG: Revert "[docs][misexpect][NFC] Fix malformed table in docs" This reverts commit a427e18896dee3cd00d5f565cfb9d7d2f26ebcec. Added: Modified: clang/docs/MisExpect.rst llvm/docs/MisExpect.rst Removed: diff --git a/clang/docs/MisExpect.rst b/clang/docs/MisExpect.rst index 29eb1269b8982..c3c8e97cb050c 100644 --- a/clang/docs/MisExpect.rst +++ b/clang/docs/MisExpect.rst @@ -64,7 +64,7 @@ Sampling. MisExpect Diagnostics are compatible with all Profiling formats. ++--+ | Profile Type | Description | ++==+ -| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang`` | +| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang``| ++--+ | IR | Profiling instrumentation added during by the LLVM backend | ++--+ diff --git a/llvm/docs/MisExpect.rst b/llvm/docs/MisExpect.rst index a9e6f8cc7006d..b4b6e2c5336dc 100644 --- a/llvm/docs/MisExpect.rst +++ b/llvm/docs/MisExpect.rst @@ -62,7 +62,7 @@ Sampling. MisExpect Diagnostics are compatible with all Profiling formats. ++--+ | Profile Type | Description | ++==+ -| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang`` | +| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang``| ++--+ | IR | Profiling instrumentation added during by the LLVM backend | ++--+ ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 61e36e8 - [safestack] Support safestack in stack size diagnostics
Author: Paul Kirth
Date: 2022-04-20T18:29:40Z
New Revision: 61e36e87df1a4ad11f752d66c90e124101fe4023
URL:
https://github.com/llvm/llvm-project/commit/61e36e87df1a4ad11f752d66c90e124101fe4023
DIFF:
https://github.com/llvm/llvm-project/commit/61e36e87df1a4ad11f752d66c90e124101fe4023.diff
LOG: [safestack] Support safestack in stack size diagnostics
Current stack size diagnostics ignore the size of the unsafe stack.
This patch attaches the size of the static portion of the unsafe stack
to the function as metadata, which can be used by the backend to emit
diagnostics regarding stack usage.
Reviewed By: phosek, mcgrathr
Differential Revision: https://reviews.llvm.org/D119996
Added:
clang/test/Frontend/stack-usage-safestack.c
Modified:
llvm/include/llvm/CodeGen/MachineFrameInfo.h
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
llvm/lib/CodeGen/MachineFunction.cpp
llvm/lib/CodeGen/PrologEpilogInserter.cpp
llvm/lib/CodeGen/SafeStack.cpp
llvm/test/CodeGen/X86/warn-stack.ll
llvm/test/Transforms/SafeStack/ARM/debug.ll
Removed:
diff --git a/clang/test/Frontend/stack-usage-safestack.c
b/clang/test/Frontend/stack-usage-safestack.c
new file mode 100644
index 0..888d40cf31866
--- /dev/null
+++ b/clang/test/Frontend/stack-usage-safestack.c
@@ -0,0 +1,20 @@
+/// Check that stack frame size warnings behave the same when safe stack is
enabled
+
+// RUN: %clang_cc1 %s -fwarn-stack-size=48 -S -o - -triple=i386-apple-darwin
2>&1 | FileCheck --check-prefix=REGULAR %s
+// RUN: %clang_cc1 %s -fwarn-stack-size=1060 -S -o - -triple=i386-apple-darwin
2>&1 | FileCheck --check-prefix=IGNORE %s
+
+// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=48 -S -o -
-triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=SAFESTACK %s
+// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=1060 -S -o -
-triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=IGNORE %s
+
+extern void init(char *buf, int size);
+extern int use_buf(char *buf, int size);
+
+// REGULAR: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in
'stackSizeWarning'
+// SAFESTACK: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in
'stackSizeWarning'
+// IGNORE-NOT: stack frame size ([[#]]) exceeds limit ([[#]]) in
'stackSizeWarning'
+void stackSizeWarning() {
+ char buf[1024];
+ init(buf, sizeof(buf));
+ if (buf[0] < 42)
+use_buf(buf, sizeof(buf));
+}
diff --git a/llvm/include/llvm/CodeGen/MachineFrameInfo.h
b/llvm/include/llvm/CodeGen/MachineFrameInfo.h
index 2d018aa73fec1..dfedf14ec118b 100644
--- a/llvm/include/llvm/CodeGen/MachineFrameInfo.h
+++ b/llvm/include/llvm/CodeGen/MachineFrameInfo.h
@@ -334,6 +334,9 @@ class MachineFrameInfo {
/// Not null, if shrink-wrapping found a better place for the epilogue.
MachineBasicBlock *Restore = nullptr;
+ /// Size of the UnsafeStack Frame
+ uint64_t UnsafeStackSize = 0;
+
public:
explicit MachineFrameInfo(unsigned StackAlignment, bool StackRealignable,
bool ForcedRealign)
@@ -787,6 +790,9 @@ class MachineFrameInfo {
MachineBasicBlock *getRestorePoint() const { return Restore; }
void setRestorePoint(MachineBasicBlock *NewRestore) { Restore = NewRestore; }
+ uint64_t getUnsafeStackSize() const { return UnsafeStackSize; }
+ void setUnsafeStackSize(uint64_t Size) { UnsafeStackSize = Size; }
+
/// Return a set of physical registers that are pristine.
///
/// Pristine registers hold a value that is useless to the current function,
diff --git a/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
b/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
index 01f6334021c28..ea8a86b2e3757 100644
--- a/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
@@ -1354,7 +1354,8 @@ void AsmPrinter::emitStackSizeSection(const
MachineFunction &MF) {
OutStreamer->SwitchSection(StackSizeSection);
const MCSymbol *FunctionSymbol = getFunctionBegin();
- uint64_t StackSize = FrameInfo.getStackSize();
+ uint64_t StackSize =
+ FrameInfo.getStackSize() + FrameInfo.getUnsafeStackSize();
OutStreamer->emitSymbolValue(FunctionSymbol, TM.getProgramPointerSize());
OutStreamer->emitULEB128IntValue(StackSize);
@@ -1369,7 +1370,8 @@ void AsmPrinter::emitStackUsage(const MachineFunction
&MF) {
return;
const MachineFrameInfo &FrameInfo = MF.getFrameInfo();
- uint64_t StackSize = FrameInfo.getStackSize();
+ uint64_t StackSize =
+ FrameInfo.getStackSize() + FrameInfo.getUnsafeStackSize();
if (StackUsageStream == nullptr) {
std::error_code EC;
diff --git a/llvm/lib/CodeGen/MachineFunction.cpp
b/llvm/lib/CodeGen/MachineFunction.cpp
index db9108872ed44..06830e852a286 100644
--- a/llvm/lib/CodeGen/MachineFunction.cpp
+++ b/llvm/lib/CodeGen/MachineFunction.cpp
@@ -107,6 +107,27 @@ static const char
*getPropertyName(MachineFunctionProperties::Property
[clang] 414f84b - [clang][safestack] Remove triple from stack usage test
Author: Paul Kirth Date: 2022-04-21T21:58:24Z New Revision: 414f84ba29d96c8cbbe198cfc022146e4582cbef URL: https://github.com/llvm/llvm-project/commit/414f84ba29d96c8cbbe198cfc022146e4582cbef DIFF: https://github.com/llvm/llvm-project/commit/414f84ba29d96c8cbbe198cfc022146e4582cbef.diff LOG: [clang][safestack] Remove triple from stack usage test Supplying the target triple caused breakeages for compilers that don't support the supplied triple. Reviewed By: mysterymath Differential Revision: https://reviews.llvm.org/D124203 Added: Modified: clang/test/Frontend/stack-usage-safestack.c Removed: diff --git a/clang/test/Frontend/stack-usage-safestack.c b/clang/test/Frontend/stack-usage-safestack.c index f6e795f8ad7b3..0d4f1348be25c 100644 --- a/clang/test/Frontend/stack-usage-safestack.c +++ b/clang/test/Frontend/stack-usage-safestack.c @@ -1,12 +1,10 @@ /// Check that stack frame size warnings behave the same when safe stack is enabled -// REQUIRES: x86-registered-target +// RUN: %clang_cc1 %s -fwarn-stack-size=48 -S -o - 2>&1 | FileCheck --check-prefix=REGULAR %s +// RUN: %clang_cc1 %s -fwarn-stack-size=1060 -S -o - 2>&1 | FileCheck --check-prefix=IGNORE %s -// RUN: %clang_cc1 %s -fwarn-stack-size=48 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=REGULAR %s -// RUN: %clang_cc1 %s -fwarn-stack-size=1060 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=IGNORE %s - -// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=48 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=SAFESTACK %s -// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=1060 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=IGNORE %s +// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=48 -S -o - 2>&1 | FileCheck --check-prefix=SAFESTACK %s +// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=1060 -S -o - 2>&1 | FileCheck --check-prefix=IGNORE %s extern void init(char *buf, int size); extern int use_buf(char *buf, int size); ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] b878641 - Revert "[clang][safestack] Remove triple from stack usage test"
Author: Paul Kirth Date: 2022-04-21T22:47:56Z New Revision: b8786413d8007f6864f0dc55d95a09c232e3 URL: https://github.com/llvm/llvm-project/commit/b8786413d8007f6864f0dc55d95a09c232e3 DIFF: https://github.com/llvm/llvm-project/commit/b8786413d8007f6864f0dc55d95a09c232e3.diff LOG: Revert "[clang][safestack] Remove triple from stack usage test" This reverts commit 414f84ba29d96c8cbbe198cfc022146e4582cbef. Requires deirectives had already been added to the test, and CC1 tests should use a target triple. Differential Revision: https://reviews.llvm.org/D124210 Added: Modified: clang/test/Frontend/stack-usage-safestack.c Removed: diff --git a/clang/test/Frontend/stack-usage-safestack.c b/clang/test/Frontend/stack-usage-safestack.c index 0d4f1348be25c..f6e795f8ad7b3 100644 --- a/clang/test/Frontend/stack-usage-safestack.c +++ b/clang/test/Frontend/stack-usage-safestack.c @@ -1,10 +1,12 @@ /// Check that stack frame size warnings behave the same when safe stack is enabled -// RUN: %clang_cc1 %s -fwarn-stack-size=48 -S -o - 2>&1 | FileCheck --check-prefix=REGULAR %s -// RUN: %clang_cc1 %s -fwarn-stack-size=1060 -S -o - 2>&1 | FileCheck --check-prefix=IGNORE %s +// REQUIRES: x86-registered-target -// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=48 -S -o - 2>&1 | FileCheck --check-prefix=SAFESTACK %s -// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=1060 -S -o - 2>&1 | FileCheck --check-prefix=IGNORE %s +// RUN: %clang_cc1 %s -fwarn-stack-size=48 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=REGULAR %s +// RUN: %clang_cc1 %s -fwarn-stack-size=1060 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=IGNORE %s + +// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=48 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=SAFESTACK %s +// RUN: %clang_cc1 %s -fsanitize=safe-stack -fwarn-stack-size=1060 -S -o - -triple=i386-apple-darwin 2>&1 | FileCheck --check-prefix=IGNORE %s extern void init(char *buf, int size); extern int use_buf(char *buf, int size); ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] 30360d8 - [clang-doc] Add check for pointer validity
Author: Paul Kirth
Date: 2022-07-22T17:36:30Z
New Revision: 30360d88d42214e75215145c4e73a74aaf93ddfd
URL:
https://github.com/llvm/llvm-project/commit/30360d88d42214e75215145c4e73a74aaf93ddfd
DIFF:
https://github.com/llvm/llvm-project/commit/30360d88d42214e75215145c4e73a74aaf93ddfd.diff
LOG: [clang-doc] Add check for pointer validity
clang-doc would SEGV when running over the Fuchsia code base.
This patch adds a check to avoid dereferencing potentially null pointers
in the Values vector. These pointers were either never valid or had been
invalidated when the underlying pointer in std::unique_ptr was moved from,
hence making it nullptr within the vector.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D130279
Added:
Modified:
clang-tools-extra/clang-doc/Representation.cpp
Removed:
diff --git a/clang-tools-extra/clang-doc/Representation.cpp
b/clang-tools-extra/clang-doc/Representation.cpp
index 8c619d2a09632..0a78d8c190db9 100644
--- a/clang-tools-extra/clang-doc/Representation.cpp
+++ b/clang-tools-extra/clang-doc/Representation.cpp
@@ -33,7 +33,7 @@ const SymbolID EmptySID = SymbolID();
template
llvm::Expected>
reduce(std::vector> &Values) {
- if (Values.empty())
+ if (Values.empty() || !Values[0])
return llvm::createStringError(llvm::inconvertibleErrorCode(),
"no value to reduce");
std::unique_ptr Merged = std::make_unique(Values[0]->USR);
@@ -95,7 +95,7 @@ void reduceChildren(std::vector &Children,
// Dispatch function.
llvm::Expected>
mergeInfos(std::vector> &Values) {
- if (Values.empty())
+ if (Values.empty() || !Values[0])
return llvm::createStringError(llvm::inconvertibleErrorCode(),
"no info values to merge");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMAKE] Enable FatLTO as a build option for LLVM (PR #80480)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/80480
>From 043e8a33f10905d456e42b71801f0ab1b24a8b36 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 22 Aug 2023 15:24:03 +
Subject: [PATCH 1/6] [CMAKE] Enable FatLTO as a build option for LLVM
---
clang/cmake/caches/Fuchsia-stage2.cmake| 1 +
llvm/cmake/modules/AddLLVM.cmake | 11 +--
llvm/cmake/modules/HandleLLVMOptions.cmake | 6 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/clang/cmake/caches/Fuchsia-stage2.cmake
b/clang/cmake/caches/Fuchsia-stage2.cmake
index db7430b3344c3e..d5546e20873b3c 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -11,6 +11,7 @@ set(LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "
set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "")
set(LLVM_ENABLE_DIA_SDK OFF CACHE BOOL "")
+set(LLVM_ENABLE_FATLTO ON CACHE BOOL "")
set(LLVM_ENABLE_HTTPLIB ON CACHE BOOL "")
set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "")
set(LLVM_ENABLE_LIBEDIT OFF CACHE BOOL "")
diff --git a/llvm/cmake/modules/AddLLVM.cmake b/llvm/cmake/modules/AddLLVM.cmake
index 5610880da71079..6fc02c993a924c 100644
--- a/llvm/cmake/modules/AddLLVM.cmake
+++ b/llvm/cmake/modules/AddLLVM.cmake
@@ -1637,8 +1637,15 @@ function(add_unittest test_suite test_name)
# The runtime benefits of LTO don't outweight the compile time costs for
tests.
if(LLVM_ENABLE_LTO)
if((UNIX OR MINGW) AND LINKER_IS_LLD)
- set_property(TARGET ${test_name} APPEND_STRING PROPERTY
-LINK_FLAGS " -Wl,--lto-O0")
+ if(LLVM_ENABLE_FATLTO)
+# When using FatLTO, just use relocatable linking.
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY
+ LINK_FLAGS " -Wl,--no-fat-lto-objects")
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY COMPILE_FLAGS
" -fno-lto")
+ else()
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY
+ LINK_FLAGS " -Wl,--lto-O0")
+ endif()
elseif(LINKER_IS_LLD_LINK)
set_property(TARGET ${test_name} APPEND_STRING PROPERTY
LINK_FLAGS " /opt:lldlto=0")
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index 745a8354f11896..a03a92b70ac300 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -32,6 +32,8 @@ endif()
set(LLVM_ENABLE_LTO OFF CACHE STRING "Build LLVM with LTO. May be specified as
Thin or Full to use a particular kind of LTO")
string(TOUPPER "${LLVM_ENABLE_LTO}" uppercase_LLVM_ENABLE_LTO)
+option(LLVM_ENABLE_FATLTO "Build LLVM with -ffat-lto-objects." OFF)
+
# Ninja Job Pool support
# The following only works with the Ninja generator in CMake >= 3.0.
set(LLVM_PARALLEL_COMPILE_JOBS "" CACHE STRING
@@ -1280,6 +1282,10 @@ elseif(LLVM_ENABLE_LTO)
endif()
endif()
+if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
+append("-ffat-lto-objects" CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
+endif()
+
# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we
are
# doing dynamic linking (see below).
set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default OFF)
>From fcec28e7b2352a9a1d92e16b4dbf1952d83049ec Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Fri, 2 Feb 2024 13:09:18 -0800
Subject: [PATCH 2/6] Add -ffat-lto-objects to CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS
---
llvm/cmake/modules/HandleLLVMOptions.cmake | 3 +++
1 file changed, 3 insertions(+)
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index a03a92b70ac300..cec45365462044 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -1283,7 +1283,10 @@ elseif(LLVM_ENABLE_LTO)
endif()
if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
+ append("-ffat-lto-objects" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+ if(NOT LINKER_IS_LLD_LINK)
append("-ffat-lto-objects" CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
+ endif()
endif()
# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we
are
>From e273686a4b127fa844af2423b4fb1c17e6552621 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 5 Mar 2024 10:08:26 -0800
Subject: [PATCH 3/6] [cmake] Append -ffat-lto-objects to
CMAKE_MODULE_LINKER_FLAGS
---
llvm/cmake/modules/HandleLLVMOptions.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index cec45365462044..92fa9839db652d 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -1285,7 +1285,7 @@ endif()
if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
append("-ffat-lto-objects" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
-append("-ffat-lto-objects" CMAKE_EXE_LI
[clang] [llvm] [CMAKE] Enable FatLTO as a build option for LLVM (PR #80480)
ilovepi wrote: Not sure what I've managed to do here w/ basic rebase ... Will remove unrelated folks and triage the commits https://github.com/llvm/llvm-project/pull/80480 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMAKE] Enable FatLTO as a build option for LLVM (PR #80480)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/80480
>From c0f09d9efd3836a83e72c329d17b32f7a87764b7 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 22 Aug 2023 15:24:03 +
Subject: [PATCH 1/4] [CMAKE] Enable FatLTO as a build option for LLVM
---
clang/cmake/caches/Fuchsia-stage2.cmake| 1 +
llvm/cmake/modules/AddLLVM.cmake | 11 +--
llvm/cmake/modules/HandleLLVMOptions.cmake | 6 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/clang/cmake/caches/Fuchsia-stage2.cmake
b/clang/cmake/caches/Fuchsia-stage2.cmake
index db7430b3344c3e..d5546e20873b3c 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -11,6 +11,7 @@ set(LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "
set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "")
set(LLVM_ENABLE_DIA_SDK OFF CACHE BOOL "")
+set(LLVM_ENABLE_FATLTO ON CACHE BOOL "")
set(LLVM_ENABLE_HTTPLIB ON CACHE BOOL "")
set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "")
set(LLVM_ENABLE_LIBEDIT OFF CACHE BOOL "")
diff --git a/llvm/cmake/modules/AddLLVM.cmake b/llvm/cmake/modules/AddLLVM.cmake
index 5610880da71079..6fc02c993a924c 100644
--- a/llvm/cmake/modules/AddLLVM.cmake
+++ b/llvm/cmake/modules/AddLLVM.cmake
@@ -1637,8 +1637,15 @@ function(add_unittest test_suite test_name)
# The runtime benefits of LTO don't outweight the compile time costs for
tests.
if(LLVM_ENABLE_LTO)
if((UNIX OR MINGW) AND LINKER_IS_LLD)
- set_property(TARGET ${test_name} APPEND_STRING PROPERTY
-LINK_FLAGS " -Wl,--lto-O0")
+ if(LLVM_ENABLE_FATLTO)
+# When using FatLTO, just use relocatable linking.
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY
+ LINK_FLAGS " -Wl,--no-fat-lto-objects")
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY COMPILE_FLAGS
" -fno-lto")
+ else()
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY
+ LINK_FLAGS " -Wl,--lto-O0")
+ endif()
elseif(LINKER_IS_LLD_LINK)
set_property(TARGET ${test_name} APPEND_STRING PROPERTY
LINK_FLAGS " /opt:lldlto=0")
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index 745a8354f11896..a03a92b70ac300 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -32,6 +32,8 @@ endif()
set(LLVM_ENABLE_LTO OFF CACHE STRING "Build LLVM with LTO. May be specified as
Thin or Full to use a particular kind of LTO")
string(TOUPPER "${LLVM_ENABLE_LTO}" uppercase_LLVM_ENABLE_LTO)
+option(LLVM_ENABLE_FATLTO "Build LLVM with -ffat-lto-objects." OFF)
+
# Ninja Job Pool support
# The following only works with the Ninja generator in CMake >= 3.0.
set(LLVM_PARALLEL_COMPILE_JOBS "" CACHE STRING
@@ -1280,6 +1282,10 @@ elseif(LLVM_ENABLE_LTO)
endif()
endif()
+if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
+append("-ffat-lto-objects" CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
+endif()
+
# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we
are
# doing dynamic linking (see below).
set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default OFF)
>From a2005ed11bd353a0db1fc5eaf0b69282287113b7 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Fri, 2 Feb 2024 13:09:18 -0800
Subject: [PATCH 2/4] Add -ffat-lto-objects to CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS
---
llvm/cmake/modules/HandleLLVMOptions.cmake | 3 +++
1 file changed, 3 insertions(+)
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index a03a92b70ac300..cec45365462044 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -1283,7 +1283,10 @@ elseif(LLVM_ENABLE_LTO)
endif()
if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
+ append("-ffat-lto-objects" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+ if(NOT LINKER_IS_LLD_LINK)
append("-ffat-lto-objects" CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
+ endif()
endif()
# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we
are
>From bce52e38cd9f53a9f82838238db9c19354ff5d0d Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 5 Mar 2024 10:08:26 -0800
Subject: [PATCH 3/4] [cmake] Append -ffat-lto-objects to
CMAKE_MODULE_LINKER_FLAGS
---
llvm/cmake/modules/HandleLLVMOptions.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index cec45365462044..92fa9839db652d 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -1285,7 +1285,7 @@ endif()
if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
append("-ffat-lto-objects" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
-append("-ffat-lto-objects" CMAKE_EXE_LI
[clang] [llvm] [CMAKE] Enable FatLTO as a build option for LLVM (PR #80480)
https://github.com/ilovepi closed https://github.com/llvm/llvm-project/pull/80480 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [cmake] Disable FatLTO in clang build for Fuchsia (PR #85677)
https://github.com/ilovepi created https://github.com/llvm/llvm-project/pull/85677 We're seeing an issue on Macs, which shouldn't be using this config, so we will temporarily disable this while we investigate. >From 56e6059431398d126420b3595d58c3c19e20613b Mon Sep 17 00:00:00 2001 From: Paul Kirth Date: Mon, 18 Mar 2024 18:27:16 + Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?= =?UTF-8?q?l=20version?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Created using spr 1.3.4 --- clang/cmake/caches/Fuchsia-stage2.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/clang/cmake/caches/Fuchsia-stage2.cmake b/clang/cmake/caches/Fuchsia-stage2.cmake index d5546e20873b3c..bc1a05345ce237 100644 --- a/clang/cmake/caches/Fuchsia-stage2.cmake +++ b/clang/cmake/caches/Fuchsia-stage2.cmake @@ -11,7 +11,7 @@ set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING " set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "") set(LLVM_ENABLE_DIA_SDK OFF CACHE BOOL "") -set(LLVM_ENABLE_FATLTO ON CACHE BOOL "") +set(LLVM_ENABLE_FATLTO OFF CACHE BOOL "") set(LLVM_ENABLE_HTTPLIB ON CACHE BOOL "") set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "") set(LLVM_ENABLE_LIBEDIT OFF CACHE BOOL "") ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [cmake] Disable FatLTO in clang build for Fuchsia (PR #85677)
https://github.com/ilovepi closed https://github.com/llvm/llvm-project/pull/85677 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang-tidy] Improve performance of google-runtime-int (PR #86596)
https://github.com/ilovepi approved this pull request. LGTM. Thanks for the quick fix. I’ll try this out later today and let you know if this completely solves the issue or if there is something else that may still warrant investigating. https://github.com/llvm/llvm-project/pull/86596 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang-tidy] Improve performance of google-runtime-int (PR #86596)
ilovepi wrote: Well, its down to about 15 minutes from 1hr 40 min, which is a pretty great improvement. 15 minutes does still seem to be too long for a file that's only 2KLOC. I know its more complex w/ headers and macros, but it does only take about 1-2 minutes to compile normally, so I feel like it should finish a bit faster than what I'm currently seeing with this patch. https://github.com/llvm/llvm-project/pull/86596 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [llvm] [clang-tidy] Restructure JSON profile structure to be parsable (PR #86821)
https://github.com/ilovepi created
https://github.com/llvm/llvm-project/pull/86821
The existing JSON output from `--enable-profile` uses the check names as
keys in the object. This limits the machine readability of the output,
as each key is unique, forcing consumers to split and parse the
substrings of the key itself to organize and extract information.
This change adapts the existing code to output more structured JSON. The
profile is now an array of 'checks', which each have a name that can be
queried and individual times for each of 'wall', 'user', 'sys', 'mem',
and 'instr'. We also make 'mem' and 'sys' non optional, since this makes
parsing uniform. Future patches can triage any inconsistency in the
numeric representation for 'mem' and 'sys', e.g. by using NAN, `0` or
another well defined sentinel value for JSON numbers.
>From eebffcd379bd4dabb8a8cd442916925822aa87bb Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Wed, 27 Mar 2024 08:54:54 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?UTF-8?q?l=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Created using spr 1.3.4
---
.../clang-tidy/ClangTidyProfiling.cpp | 4 +--
.../clang-tidy-store-check-profile-one-tu.cpp | 29 ---
llvm/lib/Support/Timer.cpp| 28 +-
3 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/clang-tools-extra/clang-tidy/ClangTidyProfiling.cpp
b/clang-tools-extra/clang-tidy/ClangTidyProfiling.cpp
index 07ab34a07cd31d..aa1e4b45a2f34c 100644
--- a/clang-tools-extra/clang-tidy/ClangTidyProfiling.cpp
+++ b/clang-tools-extra/clang-tidy/ClangTidyProfiling.cpp
@@ -45,9 +45,9 @@ void ClangTidyProfiling::printAsJSON(llvm::raw_ostream &OS) {
OS << "{\n";
OS << R"("file": ")" << Storage->SourceFilename << "\",\n";
OS << R"("timestamp": ")" << Storage->Timestamp << "\",\n";
- OS << "\"profile\": {\n";
+ OS << "\"profile\": [\n";
TG->printJSONValues(OS, "");
- OS << "\n}\n";
+ OS << "\n]\n";
OS << "}\n";
OS.flush();
}
diff --git
a/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
b/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
index f0939f71edc073..17f6a21db30cf3 100644
---
a/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
+++
b/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
@@ -14,22 +14,31 @@
// CHECK-FILE: {
// CHECK-FILE-NEXT:"file": "{{.*}}clang-tidy-store-check-profile-one-tu.cpp",
// CHECK-FILE-NEXT:"timestamp": "{{[0-9]+}}-{{[0-9]+}}-{{[0-9]+}}
{{[0-9]+}}:{{[0-9]+}}:{{[0-9]+}}.{{[0-9]+}}",
-// CHECK-FILE-NEXT:"profile": {
-// CHECK-FILE-NEXT:"time.clang-tidy.readability-function-size.wall":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
-// CHECK-FILE-NEXT:"time.clang-tidy.readability-function-size.user":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
-// CHECK-FILE-NEXT:"time.clang-tidy.readability-function-size.sys":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}{{,?}}
-// If available on the platform, we also have a
"time.clang-tidy.readability-function-size.instr" entry
-// CHECK-FILE: }
+// CHECK-FILE-NEXT:"profile": [
+// CHECK-FILE-NEXT: "check": {
+// CHECK-FILE-NEXT:"name": "clang-tidy.readability-function-size",
+// CHECK-FILE-NEXT: "wall":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
+// CHECK-FILE-NEXT:"user":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
+// CHECK-FILE-NEXT:"sys":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}{{,?}}
+// CHECK-FILE-NEXT:"mem":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
+// CHECK-FILE-NEXT:"instr":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}
+// CHECK-FILE-NEXT: }
+// CHECK-FILE: ]
// CHECK-FILE-NEXT: }
// CHECK-FILE-NOT: {
// CHECK-FILE-NOT: "file":
{{.*}}clang-tidy-store-check-profile-one-tu.cpp{{.*}},
// CHECK-FILE-NOT: "timestamp": "{{[0-9]+}}-{{[0-9]+}}-{{[0-9]+}}
{{[0-9]+}}:{{[0-9]+}}:{{[0-9]+}}.{{[0-9]+}}",
-// CHECK-FILE-NOT: "profile": {
-// CHECK-FILE-NOT: "time.clang-tidy.readability-function-size.wall":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
-// CHECK-FILE-NOT: "time.clang-tidy.readability-function-size.user":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
-// CHECK-FILE-NOT: "time.clang-tidy.readability-function-size.sys":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}{{,?}}
+// CHECK-FILE-NOT: "profile": [
+// CHECK-FILE-NOT: "check": {
+// CHECK-FILE-NOT: "name": "clang-tidy.readability-function-size",
+// CHECK-FILE-NOT: "wall":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
+// CHECK-FILE-NOT: "user":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
+// CHECK-FILE-NOT: "sys":
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{
[clang] [llvm] [RISCV] Add Zicfiss support to the shadow call stack implementation. (PR #68075)
https://github.com/ilovepi approved this pull request. LGTM. Seems like all of my comments have been addressed. Thanks for the hard work! https://github.com/llvm/llvm-project/pull/68075 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][driver] Set TLSDESC as the default for Android on RISC-V (PR #81198)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/81198
>From 3221a5e60c58e64dabdf23c52d33ba7ed5bdf81e Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Thu, 8 Feb 2024 14:21:49 -0800
Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Created using spr 1.3.4
---
llvm/include/llvm/TargetParser/Triple.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/llvm/include/llvm/TargetParser/Triple.h
b/llvm/include/llvm/TargetParser/Triple.h
index 98d8490cc9f7a2..0382d97d3fe38b 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -1036,8 +1036,7 @@ class Triple {
/// True if the target supports both general-dynamic and TLSDESC, and TLSDESC
/// is enabled by default.
bool hasDefaultTLSDESC() const {
-// TODO: Improve check for other platforms, like Android, and RISC-V
-return false;
+return isAndroid() && (!isAndroidVersionLT(29) || isRISCV64());
}
/// Tests whether the target uses -data-sections as default.
>From 567ccdff99f28cbf9598628e0150458f6302cc28 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Thu, 8 Feb 2024 16:15:07 -0800
Subject: [PATCH 2/2] Update test to check for defaults on Android (enabled)
and Linux (not enabled)
Created using spr 1.3.4
---
clang/test/Driver/tls-dialect.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/clang/test/Driver/tls-dialect.c b/clang/test/Driver/tls-dialect.c
index 4e105ce3cea5d9..f309f4a44fbc3f 100644
--- a/clang/test/Driver/tls-dialect.c
+++ b/clang/test/Driver/tls-dialect.c
@@ -3,6 +3,11 @@
// RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck
--check-prefix=NODESC %s
// RUN: %clang -### --target=x86_64-linux -mtls-dialect=gnu %s 2>&1 |
FileCheck --check-prefix=NODESC %s
+/// Android supports TLSDESC by default after Android version 29 and all RISC-V
+/// TLSDESC is not on by default in Linux, even on RISC-V
+// RUN: %clang -### --target=riscv64-android %s 2>&1 | FileCheck
--check-prefix=DESC %s
+// RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck
--check-prefix=NODESC %s
+
/// LTO
// RUN: %clang -### --target=riscv64-linux -flto -mtls-dialect=desc %s 2>&1 |
FileCheck --check-prefix=LTO-DESC %s
// RUN: %clang -### --target=riscv64-linux -flto %s 2>&1 | FileCheck
--check-prefix=LTO-NODESC %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][driver] Set TLSDESC as the default for Android on RISC-V (PR #81198)
ilovepi wrote: Sounds good. I’ll update this when I have a chance tomorrow. https://github.com/llvm/llvm-project/pull/81198 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][driver] Set TLSDESC as the default for Android on RISC-V (PR #81198)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/81198
>From 3221a5e60c58e64dabdf23c52d33ba7ed5bdf81e Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Thu, 8 Feb 2024 14:21:49 -0800
Subject: [PATCH 1/3] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Created using spr 1.3.4
---
llvm/include/llvm/TargetParser/Triple.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/llvm/include/llvm/TargetParser/Triple.h
b/llvm/include/llvm/TargetParser/Triple.h
index 98d8490cc9f7a2..0382d97d3fe38b 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -1036,8 +1036,7 @@ class Triple {
/// True if the target supports both general-dynamic and TLSDESC, and TLSDESC
/// is enabled by default.
bool hasDefaultTLSDESC() const {
-// TODO: Improve check for other platforms, like Android, and RISC-V
-return false;
+return isAndroid() && (!isAndroidVersionLT(29) || isRISCV64());
}
/// Tests whether the target uses -data-sections as default.
>From 567ccdff99f28cbf9598628e0150458f6302cc28 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Thu, 8 Feb 2024 16:15:07 -0800
Subject: [PATCH 2/3] Update test to check for defaults on Android (enabled)
and Linux (not enabled)
Created using spr 1.3.4
---
clang/test/Driver/tls-dialect.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/clang/test/Driver/tls-dialect.c b/clang/test/Driver/tls-dialect.c
index 4e105ce3cea5d9..f309f4a44fbc3f 100644
--- a/clang/test/Driver/tls-dialect.c
+++ b/clang/test/Driver/tls-dialect.c
@@ -3,6 +3,11 @@
// RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck
--check-prefix=NODESC %s
// RUN: %clang -### --target=x86_64-linux -mtls-dialect=gnu %s 2>&1 |
FileCheck --check-prefix=NODESC %s
+/// Android supports TLSDESC by default after Android version 29 and all RISC-V
+/// TLSDESC is not on by default in Linux, even on RISC-V
+// RUN: %clang -### --target=riscv64-android %s 2>&1 | FileCheck
--check-prefix=DESC %s
+// RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck
--check-prefix=NODESC %s
+
/// LTO
// RUN: %clang -### --target=riscv64-linux -flto -mtls-dialect=desc %s 2>&1 |
FileCheck --check-prefix=LTO-DESC %s
// RUN: %clang -### --target=riscv64-linux -flto %s 2>&1 | FileCheck
--check-prefix=LTO-NODESC %s
>From d6f3c082e63ebf81e5b49decbdfe091de79a96a2 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Fri, 9 Feb 2024 10:21:02 -0800
Subject: [PATCH 3/3] Remove redundant RUN line and remove Android version
check
Created using spr 1.3.4
---
clang/test/Driver/tls-dialect.c | 5 ++---
llvm/include/llvm/TargetParser/Triple.h | 4 +---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/clang/test/Driver/tls-dialect.c b/clang/test/Driver/tls-dialect.c
index f309f4a44fbc3f..f73915b28ec2a3 100644
--- a/clang/test/Driver/tls-dialect.c
+++ b/clang/test/Driver/tls-dialect.c
@@ -3,10 +3,9 @@
// RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck
--check-prefix=NODESC %s
// RUN: %clang -### --target=x86_64-linux -mtls-dialect=gnu %s 2>&1 |
FileCheck --check-prefix=NODESC %s
-/// Android supports TLSDESC by default after Android version 29 and all RISC-V
-/// TLSDESC is not on by default in Linux, even on RISC-V
+/// Android supports TLSDESC by default on RISC-V
+/// TLSDESC is not on by default in Linux, even on RISC-V, and is covered above
// RUN: %clang -### --target=riscv64-android %s 2>&1 | FileCheck
--check-prefix=DESC %s
-// RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck
--check-prefix=NODESC %s
/// LTO
// RUN: %clang -### --target=riscv64-linux -flto -mtls-dialect=desc %s 2>&1 |
FileCheck --check-prefix=LTO-DESC %s
diff --git a/llvm/include/llvm/TargetParser/Triple.h
b/llvm/include/llvm/TargetParser/Triple.h
index 0382d97d3fe38b..e73207021392ec 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -1035,9 +1035,7 @@ class Triple {
/// True if the target supports both general-dynamic and TLSDESC, and TLSDESC
/// is enabled by default.
- bool hasDefaultTLSDESC() const {
-return isAndroid() && (!isAndroidVersionLT(29) || isRISCV64());
- }
+ bool hasDefaultTLSDESC() const { return isAndroid() && isRISCV64(); }
/// Tests whether the target uses -data-sections as default.
bool hasDefaultDataSections() const {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][driver] Set TLSDESC as the default for Android on RISC-V (PR #81198)
https://github.com/ilovepi edited https://github.com/llvm/llvm-project/pull/81198 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][driver] Set TLSDESC as the default for Android on RISC-V (PR #81198)
@@ -3,6 +3,11 @@ // RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck --check-prefix=NODESC %s // RUN: %clang -### --target=x86_64-linux -mtls-dialect=gnu %s 2>&1 | FileCheck --check-prefix=NODESC %s +/// Android supports TLSDESC by default after Android version 29 and all RISC-V +/// TLSDESC is not on by default in Linux, even on RISC-V +// RUN: %clang -### --target=riscv64-android %s 2>&1 | FileCheck --check-prefix=DESC %s +// RUN: %clang -### --target=riscv64-linux %s 2>&1 | FileCheck --check-prefix=NODESC %s ilovepi wrote: That's a good point. I went ahead and updated the comment to point that out. https://github.com/llvm/llvm-project/pull/81198 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][driver] Set TLSDESC as the default for Android on RISC-V (PR #81198)
https://github.com/ilovepi closed https://github.com/llvm/llvm-project/pull/81198 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMAKE] Enable FatLTO as a build option for LLVM (PR #80480)
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/80480
>From 1946ea0be5b87da44e05a5e668e383c3c463cdd7 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 22 Aug 2023 15:24:03 +
Subject: [PATCH 1/3] [CMAKE] Enable FatLTO as a build option for LLVM
---
clang/cmake/caches/Fuchsia-stage2.cmake| 1 +
llvm/cmake/modules/AddLLVM.cmake | 11 +--
llvm/cmake/modules/HandleLLVMOptions.cmake | 6 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/clang/cmake/caches/Fuchsia-stage2.cmake
b/clang/cmake/caches/Fuchsia-stage2.cmake
index eee37c5e7901fa..d5a1662cbf4aa6 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -11,6 +11,7 @@ set(LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "
set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "")
set(LLVM_ENABLE_DIA_SDK OFF CACHE BOOL "")
+set(LLVM_ENABLE_FATLTO ON CACHE BOOL "")
set(LLVM_ENABLE_HTTPLIB ON CACHE BOOL "")
set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "")
set(LLVM_ENABLE_LIBEDIT OFF CACHE BOOL "")
diff --git a/llvm/cmake/modules/AddLLVM.cmake b/llvm/cmake/modules/AddLLVM.cmake
index 828de4bd9940d6..2228237645be63 100644
--- a/llvm/cmake/modules/AddLLVM.cmake
+++ b/llvm/cmake/modules/AddLLVM.cmake
@@ -1621,8 +1621,15 @@ function(add_unittest test_suite test_name)
# The runtime benefits of LTO don't outweight the compile time costs for
tests.
if(LLVM_ENABLE_LTO)
if((UNIX OR MINGW) AND LINKER_IS_LLD)
- set_property(TARGET ${test_name} APPEND_STRING PROPERTY
-LINK_FLAGS " -Wl,--lto-O0")
+ if(LLVM_ENABLE_FATLTO)
+# When using FatLTO, just use relocatable linking.
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY
+ LINK_FLAGS " -Wl,--no-fat-lto-objects")
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY COMPILE_FLAGS
" -fno-lto")
+ else()
+set_property(TARGET ${test_name} APPEND_STRING PROPERTY
+ LINK_FLAGS " -Wl,--lto-O0")
+ endif()
elseif(LINKER_IS_LLD_LINK)
set_property(TARGET ${test_name} APPEND_STRING PROPERTY
LINK_FLAGS " /opt:lldlto=0")
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index eca2962cf82071..38876a5d19ad9f 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -32,6 +32,8 @@ endif()
set(LLVM_ENABLE_LTO OFF CACHE STRING "Build LLVM with LTO. May be specified as
Thin or Full to use a particular kind of LTO")
string(TOUPPER "${LLVM_ENABLE_LTO}" uppercase_LLVM_ENABLE_LTO)
+option(LLVM_ENABLE_FATLTO "Build LLVM with -ffat-lto-objects." OFF)
+
# Ninja Job Pool support
# The following only works with the Ninja generator in CMake >= 3.0.
set(LLVM_PARALLEL_COMPILE_JOBS "" CACHE STRING
@@ -1258,6 +1260,10 @@ elseif(LLVM_ENABLE_LTO)
endif()
endif()
+if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
+append("-ffat-lto-objects" CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
+endif()
+
# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we
are
# doing dynamic linking (see below).
set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default OFF)
>From 51b1d85ee4b0f476bece474784da504052271a5e Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Fri, 2 Feb 2024 13:09:18 -0800
Subject: [PATCH 2/3] Add -ffat-lto-objects to CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS
---
llvm/cmake/modules/HandleLLVMOptions.cmake | 3 +++
1 file changed, 3 insertions(+)
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index 38876a5d19ad9f..10f466a3e5207d 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -1261,7 +1261,10 @@ elseif(LLVM_ENABLE_LTO)
endif()
if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
+ append("-ffat-lto-objects" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+ if(NOT LINKER_IS_LLD_LINK)
append("-ffat-lto-objects" CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
+ endif()
endif()
# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we
are
>From d4d997a7775962abd39644e3fb957fa007baa518 Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 5 Mar 2024 10:08:26 -0800
Subject: [PATCH 3/3] [cmake] Append -ffat-lto-objects to
CMAKE_MODULE_LINKER_FLAGS
---
llvm/cmake/modules/HandleLLVMOptions.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index 10f466a3e5207d..425a98315e2cc1 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -1263,7 +1263,7 @@ endif()
if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
append("-ffat-lto-objects" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
-append("-ffat-lto-objects" CMAKE_EXE_LI
[clang] [llvm] [CMAKE] Enable FatLTO as a build option for LLVM (PR #80480)
@@ -1251,6 +1253,10 @@ elseif(LLVM_ENABLE_LTO)
endif()
endif()
+if(LLVM_ENABLE_FATLTO AND (FUCHSIA OR UNIX))
+append("-ffat-lto-objects" CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
ilovepi wrote:
done. Thanks for the suggestion.
https://github.com/llvm/llvm-project/pull/80480
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [X86] Add Support for X86 TLSDESC Relocations (PR #83136)
@@ -740,7 +740,8 @@ bool tools::isTLSDESCEnabled(const ToolChain &TC,
SupportedArgument = V == "desc" || V == "trad";
EnableTLSDESC = V == "desc";
} else if (Triple.isX86()) {
-SupportedArgument = V == "gnu";
+SupportedArgument = V == "gnu" || V == "gnu2";
+EnableTLSDESC = V == "gnu2";
ilovepi wrote:
Is it possible to make this option work uniformly with `trad` and `desc` too?
The `gnu`/`gnu2` spelling is something we need to support for compatibility,
but it would be good if we can get this to be consistent in clang. I'm hoping
we can get GCC to accept the same set of options.
@MaskRay does that sound reasonable to you?
https://github.com/llvm/llvm-project/pull/83136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [X86] Add Support for X86 TLSDESC Relocations (PR #83136)
https://github.com/ilovepi commented: I assume that's what you're doing in the place I asked for a comment is trying to avoid redundantly generating TLSDESC accesses for _TLS_MODULE_BASE_. I see that we don't generate multiple accesses for _TLS_MODULE_BASE_ in the test cases, but I thought that was only safe to do when an earlier access dominates a later access. Is my understanding here correct, or is there an interaction with https://github.com/llvm/llvm-project/blob/04a271ebe4c2421f34a4fbf34c328df9f111/llvm/lib/Target/X86/X86InstrInfo.cpp#L10245 ? https://github.com/llvm/llvm-project/pull/83136 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
