https://github.com/aeubanks created
https://github.com/llvm/llvm-project/pull/69030
The performance of cold functions shouldn't matter too much, so if we care
about binary sizes, add an option to mark cold functions as optsize/minsize for
binary size, or optnone for compile times [1]. Clang pa
aeubanks wrote:
still need to do measurements with this new approach, but lmk if this makes
sense
https://github.com/llvm/llvm-project/pull/69030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
llvmbot wrote:
@llvm/pr-subscribers-lto
Author: Arthur Eubanks (aeubanks)
Changes
The performance of cold functions shouldn't matter too much, so if we care
about binary sizes, add an option to mark cold functions as optsize/minsize for
binary size, or optnone for compile times [1]. Clan
@@ -27,10 +27,12 @@ class FileSystem;
struct PGOOptions {
enum PGOAction { NoAction, IRInstr, IRUse, SampleUse };
enum CSPGOAction { NoCSAction, CSIRInstr, CSIRUse };
+ enum class ColdFuncAttr { None, OptSize, MinSize, OptNone };
david-xl wrote:
Even thou
@@ -44,6 +46,7 @@ struct PGOOptions {
std::string MemoryProfile;
PGOAction Action;
CSPGOAction CSAction;
+ ColdFuncAttr ColdType;
david-xl wrote:
ColdType --> ColdOptType
https://github.com/llvm/llvm-project/pull/69030
_
@@ -27,10 +27,12 @@ class FileSystem;
struct PGOOptions {
enum PGOAction { NoAction, IRInstr, IRUse, SampleUse };
enum CSPGOAction { NoCSAction, CSIRInstr, CSIRUse };
+ enum class ColdFuncAttr { None, OptSize, MinSize, OptNone };
david-xl wrote:
None -->
@@ -0,0 +1,65 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
@@ -202,6 +202,18 @@ static cl::opt
cl::desc("Path to the profile remapping file."),
cl::Hidden);
+static cl::opt PGOColdFuncAttr(
+"pgo-cold-func-attr", cl::init(PGOOptions::ColdFuncAttr::None), cl::Hidden,
---
@@ -0,0 +1,65 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
@@ -0,0 +1,65 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
@@ -1127,6 +1134,11 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
if (EnableSyntheticCounts && !PGOOpt)
MPM.addPass(SyntheticCountsPropagation());
+ if (EnableMarkColdFunctions && PGOOpt &&
+ (PGOOpt->Action == PGOOptions::SampleUse ||
@@ -0,0 +1,28 @@
+//===- MarkColdFunctions.h - *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -0,0 +1,65 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
@@ -0,0 +1,73 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
MatzeB wrote:
How does this relate to the existing `shouldOptimizeForSize(Function&)` and
similar APIs which appear to provide similar functionality at a first glance.
If they are the same, then we should have a plan in place to cleanup and only
have one system afterwards, if there are importa
@@ -0,0 +1,73 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
WenleiHe wrote:
> > How does this relate to the existing `shouldOptimizeForSize(Function&,
> > ...)` and `shouldOptimizeForSize(MachineFunction&, ...)` APIs which appear
> > to provide similar functionality at a first glance. If they are the same,
> > then we should have a plan in place to cle
aeubanks wrote:
> How does this relate to the existing `shouldOptimizeForSize(Function&, ...)`
> and `shouldOptimizeForSize(MachineFunction&, ...)` APIs which appear to
> provide similar functionality at a first glance. If they are the same, then
> we should have a plan in place to cleanup and
aeubanks wrote:
> FWIW we've tried this with sampling PGO in the past. While on paper this
> seems like an obvious thing to do, in reality aggressively tuning down opt
> level for cold functions can lead to regression since profile isn't always
> accurate.
>
> That said, as long as this chang
@@ -0,0 +1,73 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
WenleiHe wrote:
> I don't understand, if you're saying the profile is accurate, then those
> functions are actually cold, so we should be able to mark them as optsize?
Accurate is not black or white. The current heuristic requires certain level of
accuracy to be effective. If you make the heur
david-xl wrote:
> > I don't understand, if you're saying the profile is accurate, then those
> > functions are actually cold, so we should be able to mark them as optsize?
>
> Accurate is not black or white. The current heuristic requires certain level
> of accuracy to be effective. If you mak
david-xl wrote:
> > > > I don't understand, if you're saying the profile is accurate, then
> > > > those functions are actually cold, so we should be able to mark them as
> > > > optsize?
> > >
> > >
> > > Accurate is not black or white. The current heuristic requires certain
> > > level of
23 matches
Mail list logo
