[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-10 Thread Teresa Johnson via Phabricator via cfe-commits 
tejohnson added a comment.

In D72404#3310704 , @aykevl wrote:

> @mehdi_amini thanks for explaining! D119342 
>  moves slightly closer to removing 
> SizeLevel from the pass pipeline setup.

I left a comment on D119342  - I think that 
is the right way to go. As mentioned there, there is still some legacy handling 
of options passed down from the driver, but over time we've been trying to move 
things to use function attributes, for the reasons @mehdi_amini mentioned. To 
expand on one of the reasons Mehdi mentioned: using function attributes 
naturally handles LTO linking in the case where one file is compiled `-flto 
-Os` and another is compiled `-flto -O2` the same way as if you compiled the 
two files with those different flags all the way down to native code without 
LTO. Using the approach in this pass you would be forced to pick either `-Os` 
or `-O2` for both files at LTO link time.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-10 Thread Ayke via Phabricator via cfe-commits 
aykevl added a comment.

@mehdi_amini thanks for explaining! D119342  
moves slightly closer to removing SizeLevel from the pass pipeline setup.

---

In other news, I found a workaround that can be used to avoid the size increase 
due to LoopRotate (until D119342  is merged). 
Basically, just pass the flags `-mllvm --rotation-max-header-size=0` to ld.lld 
when compiling with `-Oz`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-09 Thread Mehdi AMINI via Phabricator via cfe-commits 
mehdi_amini added a comment.

In D72404#3307623 , @aykevl wrote:

> So, should all passes just look at the `optsize` and `minsize` attributes 
> instead of the `SizeLevel`? In other words, should 
> `PassManagerBuilder.SizeLevel` be removed and should passes only look at 
> function attributes instead of `SizeLevel`? Because at the moment, it's a 
> weird mix of both. IMHO size level should either all go via function 
> attributes or via a flag, not something in between as it is now.

I agree, I don't know (other than history) why we couldn't move towards 
removing `PassManagerBuilder.SizeLevel`?

> Also, if size level is done via function attributes, why not optimization 
> level? There is already `optnone`. I'm not saying that's better, but right 
> now I don't see the logic in this whole system.

Despite what gcc and clang exposes to their users, at the LLVM level we don't 
have a single dimension on which to put `O1/O2/O3` compared to `Os/Oz`. These 
also may not make sense for every single compiler out-there: `O1/O2/O3` for 
clang may not be the right pass pipeline for my proprietary shader compiler.
Another reason why O1 /O2 
/O3 
 are not making much such to be in 
the IR is that the IR is intended to be stored and reloaded any time in the 
middle of pipeline. LTO is an example of this, so we don't really want to store 
the "list of pass to run" in the IR.
Finally, we don't want to (or we can't really...) teach passes about whether 
they should execute during O1 /O2 
/O3 
, while `optnone` is just a "fuse" 
to disable them all. It is also convenient to have `optnone` as a function 
attribute because it allows to selectively disable the optimizer on a per 
function basis. On the other hand because of the nature of the pass pipeline, 
it can't be tweaked on a per function basis (what about Module passes?).

On the other hand the optsize/minsize are driving heuristic and can be 
orthogonal to the pass pipeline / controlled on a per-function basis and made 
available to every pass: they convey an "optimization goal" that applies to 
every pass individually.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-09 Thread Ayke via Phabricator via cfe-commits 
aykevl added a comment.

After some more testing on a larger amount of code (many small programs, 
together over 1MB of code), LoopRotate indeed seems to be the culprit. I'm now 
looking into a patch to LoopRotate to respect the `optsize` function attribute.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-09 Thread Ayke via Phabricator via cfe-commits 
aykevl added a comment.

Apparently there is also another patch that tries to do something very similar: 
D81223 .

In D72404#3305275 , @mehdi_amini wrote:

> Why can't you build the object files with `-Os` in the first place instead of 
> changing the optimization level between the compilation and the linking 
> phases?

I'm not changing the optimization level. The bitcode files are built with an 
equivalent of `-Oz` and have the `optsize` and `minsize` attributes. It's the 
optimization passes in the linker (ThinLTO) that don't respect these attributes.

In D72404#3305267 , @steven_wu wrote:

> Before I say yes or no to this patch, have you figured out what are the 
> passes that causes the most size regression? Ideally, with function 
> attributes on the function, it shouldn't be much size impact on the output.

Unfortunately, there is an impact. I did a quick test with a small program 
(around 4.7kB compiled code) and it looks like the LoopRotate pass is the main 
culprit. If `MaxHeaderSize` is set to 0 instead of -1, the code size regression 
is avoided. The following hacky patch avoids the code size increase:

  diff --git a/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp 
b/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
  index aa916345954d..99be1926cf34 100644
  --- a/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
  +++ b/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
  @@ -450,7 +450,7 @@ void PassManagerBuilder::addFunctionSimplificationPasses(
 // TODO: Investigate promotion cap for O1.
 MPM.add(createLICMPass(LicmMssaOptCap, LicmMssaNoAccForPromotionCap));
 // Rotate Loop - disable header duplication at -Oz
  -  MPM.add(createLoopRotatePass(SizeLevel == 2 ? 0 : -1, PrepareForLTO));
  +  MPM.add(createLoopRotatePass(0/*SizeLevel == 2 ? 0 : -1*/, PrepareForLTO));
 // TODO: Investigate promotion cap for O1.
 MPM.add(createLICMPass(LicmMssaOptCap, LicmMssaNoAccForPromotionCap));
 if (EnableSimpleLoopUnswitch)
  @@ -917,7 +917,7 @@ void PassManagerBuilder::populateModulePassManager(
 // Re-rotate loops in all our loop nests. These may have fallout out of
 // rotated form due to GVN or other transformations, and the vectorizer 
relies
 // on the rotated form. Disable header duplication at -Oz.
  -  MPM.add(createLoopRotatePass(SizeLevel == 2 ? 0 : -1, PrepareForLTO));
  +  MPM.add(createLoopRotatePass(0 /*SizeLevel == 2 ? 0 : -1*/, 
PrepareForLTO));
   
 // Distribute loops to allow partial vectorization.  I.e. isolate 
dependences
 // into separate loop that would otherwise inhibit vectorization.  This is

So, should all passes just look at the `optsize` and `minsize` attributes 
instead of the `SizeLevel`? In other words, should 
`PassManagerBuilder.SizeLevel` be removed and should passes only look at 
function attributes instead of `SizeLevel`? Because at the moment, it's a weird 
mix of both. IMHO size level should either all go via function attributes or 
via a flag, not something in between as it is now.
Also, if size level is done via function attributes, why not optimization 
level? There is already `optnone`. I'm not saying that's better, but right now 
I don't see the logic in this whole system.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-08 Thread Mehdi AMINI via Phabricator via cfe-commits 
mehdi_amini added a comment.

In D72404#3304205 , @aykevl wrote:

> I would be very interested in this patch, because for me to use ThinLTO 
> without size regressions I need to set the optimization size level in the 
> linker (`PassManagerBuilder.SizeLevel` etc).

Why can't you build the object files with `-Os` in the first place instead of 
changing the optimization level between the compilation and the linking phases?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-08 Thread Steven Wu via Phabricator via cfe-commits 
steven_wu added a comment.

I just saw this. I know it is a good idea to have choice during link time for 
the pipeline configuration and from your benchmark it also has size impact on 
the output. I also feel like this is going in the wrong direction as if I have 
part of the object files built with -O3 and part built with -Oz, I need to make 
a choice of unoptimized part of the program.

Before I say yes or no to this patch, have you figured out what are the passes 
that causes the most size regression? Ideally, with function attributes on the 
function, it shouldn't be much size impact on the output.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2022-02-08 Thread Ayke via Phabricator via cfe-commits 
aykevl added a comment.
Herald added a reviewer: MaskRay.

I would be very interested in this patch, because for me to use ThinLTO without 
size regressions I need to set the optimization size level in the linker 
(`PassManagerBuilder.SizeLevel` etc).
This patch seems mostly correct to me, except for the function attributes. 
These function attributes (`optsize`, `minsize`) should IMHO be set in the 
frontend, not in the linker.

Apart from that, would it be reasonable to implement this in the form of 
`-plugin-opt=Os` and `-plugin-opt=Oz`? That is perhaps a cleaner UI (doesn't 
need a new flag!) and more cleanly maps to `PassBuilder::Oz` and the like.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits 
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61859 tests passed, 0 failed 
and 781 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread Yuanfang Chen via Phabricator via cfe-commits 
ychen updated this revision to Diff 238142.
ychen edited the summary of this revision.
ychen added a comment.

- fix test when clang is the host compiler


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/thinlto-debug-pm.c
  lld/COFF/Config.h
  lld/COFF/Driver.cpp
  lld/COFF/LTO.cpp
  lld/ELF/Config.h
  lld/ELF/Driver.cpp
  lld/ELF/LTO.cpp
  lld/test/COFF/lto-opt-level.ll
  lld/test/ELF/lto/opt-level.ll
  lld/test/wasm/lto/opt-level.ll
  lld/wasm/Config.h
  lld/wasm/Driver.cpp
  lld/wasm/LTO.cpp
  llvm/include/llvm/LTO/Config.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h
  llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/test/LTO/X86/Inputs/opt-level-size.ll
  llvm/test/LTO/X86/opt-level-size.ll
  llvm/test/tools/lto/opt-level.ll
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp
  llvm/tools/lto/lto.cpp

Index: llvm/tools/lto/lto.cpp
===
--- llvm/tools/lto/lto.cpp
+++ llvm/tools/lto/lto.cpp
@@ -28,14 +28,13 @@
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/raw_ostream.h"
 
-// extra command-line flags needed for LTOCodeGenerator
-static cl::opt
+static cl::opt
 OptLevel("O",
- cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
+ cl::desc("Optimization level. [-O0, -O1, -O2, -Os, -Oz or -O3] "
   "(default = '-O2')"),
  cl::Prefix,
  cl::ZeroOrMore,
- cl::init('2'));
+ cl::init("2"));
 
 static cl::opt
 DisableInline("disable-inlining", cl::init(false),
@@ -165,9 +164,15 @@
 CG->setAttr(attrs);
   }
 
-  if (OptLevel < '0' || OptLevel > '3')
-report_fatal_error("Optimization level must be between 0 and 3");
-  CG->setOptLevel(OptLevel - '0');
+  LLVMContext &Ctx = CG->getContext();
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getOptLevel(OptLevel)))
+CG->setOptLevel(*Result);
+
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getSizeLevel(OptLevel)))
+CG->setSizeLevel(*Result);
+
   CG->setFreestanding(EnableFreestanding);
 }
 
@@ -487,25 +492,19 @@
   CodeGen->setTargetOptions(InitTargetOptionsFromCodeGenFlags());
   CodeGen->setFreestanding(EnableFreestanding);
 
-  if (OptLevel.getNumOccurrences()) {
-if (OptLevel < '0' || OptLevel > '3')
-  report_fatal_error("Optimization level must be between 0 and 3");
-CodeGen->setOptLevel(OptLevel - '0');
-switch (OptLevel) {
-case '0':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::None);
-  break;
-case '1':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Less);
-  break;
-case '2':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Default);
-  break;
-case '3':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Aggressive);
-  break;
-}
-  }
+  LLVMContext Ctx;
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getOptLevel(OptLevel)))
+CodeGen->setOptLevel(*Result);
+  else
+return nullptr;
+
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getSizeLevel(OptLevel)))
+CodeGen->setSizeLevel(*Result);
+  else
+return nullptr;
+
   return wrap(CodeGen);
 }
 
Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -29,10 +29,11 @@
 using namespace llvm;
 using namespace lto;
 
-static cl::opt
-OptLevel("O", cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
-   "(default = '-O2')"),
- cl::Prefix, cl::ZeroOrMore, cl::init('2'));
+static cl::opt
+OptLevel("O",
+ cl::desc("Optimization level. [-O0, -O1, -O2, -Os, -Oz, or "
+  "-O3] (default = '-O2')"),
+ cl::Prefix, cl::ZeroOrMore, cl::init("2"));
 
 static cl::opt CGOptLevel(
 "cg-opt-level",
@@ -244,7 +245,10 @@
   Conf.OptPipeline = OptPipeline;
   Conf.AAPipeline = AAPipeline;
 
-  Conf.OptLevel = OptLevel - '0';
+  Conf.OptLevel =
+  check(llvm::lto::getOptLevel(OptLevel), "invalid optimization level");
+  Conf.SizeLevel =
+  check(llvm::lto::getSizeLevel(OptLevel), "invalid optimization level");
   Conf.UseNewPM = UseNewPM;
   switch (CGOptLevel) {
   case '0':
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -62,10 +62,11 @@
 
 using namespace llvm;
 
-static cl::opt
-OptLevel("O", cl::desc("Optimization le

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread Yuanfang Chen via Phabricator via cfe-commits 
ychen added a comment.

In D72404#1820628 , @tycho wrote:

> In D72404#1820461 , 
> @merge_guards_bot wrote:
>
> > {icon times-circle color=red} Unit tests: fail. 61858 tests passed, 1 
> > failed and 781 were skipped.
> >
> >   failed: Clang.CodeGen/thinlto-debug-pm.c
>
>
> I think that failure can be fixed with something like this:
>
>   diff --git a/clang/test/CodeGen/thinlto-debug-pm.c 
> b/clang/test/CodeGen/thinlto-debug-pm.c
>index 5f449d493af..9d6d69afd13 100644
>--- a/clang/test/CodeGen/thinlto-debug-pm.c
>+++ b/clang/test/CodeGen/thinlto-debug-pm.c
>@@ -13,17 +13,17 @@
> // O0123sz-NEWPM: Running analysis: PassInstrumentationAnalysis
> // O0123sz-NEWPM: Starting llvm::Module pass manager run.
> // O0123sz-NEWPM: Running pass: WholeProgramDevirtPass
>-// O0123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O0123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy
> // O0123sz-NEWPM: Running pass: LowerTypeTestsPass
> // O0123sz-NEWPM: Invalidating all non-preserved analyses for:
>-// O0123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O0123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running pass: ForceFunctionAttrsPass
> // O123sz-NEWPM: Running pass: PassManager
> // O123sz-NEWPM: Starting llvm::Module pass manager run.
> // O123sz-NEWPM: Running pass: PGOIndirectCallPromotion
> // O123sz-NEWPM: Running analysis: ProfileSummaryAnalysis
> // O123sz-NEWPM: Running pass: InferFunctionAttrsPass
>-// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running pass: 
> ModuleToFunctionPassAdaptor >
> // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
> // O123sz-NEWPM: Starting llvm::Function pass manager run.
>@@ -41,9 +41,9 @@
> // O123sz-NEWPM: Running pass: CalledValuePropagationPass
> // O123sz-NEWPM: Running pass: GlobalOptPass
> // O123sz-NEWPM: Invalidating all non-preserved analyses for:
>-// O123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O123sz-NEWPM: Invalidating analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running pass: 
> ModuleToFunctionPassAdaptor
>-// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy, llvm::Module>
>+// O123sz-NEWPM: Running analysis: 
> InnerAnalysisManagerProxy
> // O123sz-NEWPM: Running analysis: DominatorTreeAnalysis on foo
> // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
> // O123sz-NEWPM: Running analysis: AssumptionAnalysis on foo
>@@ -57,7 +57,7 @@
> // O123sz-NEWPM: Running analysis: BasicAA on foo
> // O123sz-NEWPM: Running analysis: ScopedNoAliasAA on foo
> // O123sz-NEWPM: Running analysis: TypeBasedAA on foo
>-// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy, 
> llvm::Function> on foo
>+// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy on foo
> // O123sz-NEWPM: Running pass: SimplifyCFGPass on foo
> // O123sz-NEWPM: Running analysis: TargetIRAnalysis on foo
> // O123sz-NEWPM: Finished llvm::Function pass manager run.
>@@ -70,7 +70,7 @@
> // O123sz-NEWPM: Running analysis: LazyCallGraphAnalysis
> // O123sz-NEWPM: Running analysis: FunctionAnalysisManagerCGSCCProxy on 
> (foo)
> // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on (foo)
>-// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy, 
> llvm::LazyCallGraph::SCC, llvm::LazyCallG>
>+// O123sz-NEWPM: Running analysis: 
> OuterAnalysisManagerProxy llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&> o>
> // O123sz-NEWPM: Starting CGSCC pass manager run.
> // O123sz-NEWPM: Running pass: InlinerPass on (foo)
> // O123sz-NEWPM: Running pass: PostOrderFunctionAttrsPass on (foo)
>   


Thank you. It turns out that GCC&Clang disagree on `__PRETTY_FUNCTION__` for 
type alias (using). will fix those.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread Steven Noonan via Phabricator via cfe-commits 
tycho added a subscriber: merge_guards_bot.
tycho added a comment.

In D72404#1820461 , @merge_guards_bot 
wrote:

> {icon times-circle color=red} Unit tests: fail. 61858 tests passed, 1 failed 
> and 781 were skipped.
>
>   failed: Clang.CodeGen/thinlto-debug-pm.c


I think that failure can be fixed with something like this:

  diff --git a/clang/test/CodeGen/thinlto-debug-pm.c 
b/clang/test/CodeGen/thinlto-debug-pm.c
  index 5f449d493af..15f366dc52d 100644
  --- a/clang/test/CodeGen/thinlto-debug-pm.c
  +++ b/clang/test/CodeGen/thinlto-debug-pm.c
  @@ -13,17 +13,17 @@
   // O0123sz-NEWPM: Running analysis: PassInstrumentationAnalysis
   // O0123sz-NEWPM: Starting llvm::Module pass manager run.
   // O0123sz-NEWPM: Running pass: WholeProgramDevirtPass
  -// O0123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O0123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy
   // O0123sz-NEWPM: Running pass: LowerTypeTestsPass
   // O0123sz-NEWPM: Invalidating all non-preserved analyses for:
  -// O0123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O0123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running pass: ForceFunctionAttrsPass
   // O123sz-NEWPM: Running pass: PassManager
   // O123sz-NEWPM: Starting llvm::Module pass manager run.
   // O123sz-NEWPM: Running pass: PGOIndirectCallPromotion
   // O123sz-NEWPM: Running analysis: ProfileSummaryAnalysis
   // O123sz-NEWPM: Running pass: InferFunctionAttrsPass
  -// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running pass: 
ModuleToFunctionPassAdaptor >
   // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
   // O123sz-NEWPM: Starting llvm::Function pass manager run.
  @@ -41,9 +41,9 @@
   // O123sz-NEWPM: Running pass: CalledValuePropagationPass
   // O123sz-NEWPM: Running pass: GlobalOptPass
   // O123sz-NEWPM: Invalidating all non-preserved analyses for:
  -// O123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O123sz-NEWPM: Invalidating analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running pass: ModuleToFunctionPassAdaptor
  -// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy, llvm::Module>
  +// O123sz-NEWPM: Running analysis: 
InnerAnalysisManagerProxy
   // O123sz-NEWPM: Running analysis: DominatorTreeAnalysis on foo
   // O123sz-NEWPM: Running analysis: PassInstrumentationAnalysis on foo
   // O123sz-NEWPM: Running analysis: AssumptionAnalysis on foo


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread pre-merge checks [bot] via Phabricator via cfe-commits 
merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 61858 tests passed, 1 failed 
and 781 were skipped.

  failed: Clang.CodeGen/thinlto-debug-pm.c

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

2020-01-14 Thread Yuanfang Chen via Phabricator via cfe-commits 
ychen updated this revision to Diff 238071.
ychen added a comment.

- rebase & clang-format


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72404/new/

https://reviews.llvm.org/D72404

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/thinlto-debug-pm.c
  lld/COFF/Config.h
  lld/COFF/Driver.cpp
  lld/COFF/LTO.cpp
  lld/ELF/Config.h
  lld/ELF/Driver.cpp
  lld/ELF/LTO.cpp
  lld/test/COFF/lto-opt-level.ll
  lld/test/ELF/lto/opt-level.ll
  lld/test/wasm/lto/opt-level.ll
  lld/wasm/Config.h
  lld/wasm/Driver.cpp
  lld/wasm/LTO.cpp
  llvm/include/llvm/LTO/Config.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h
  llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/test/LTO/X86/Inputs/opt-level-size.ll
  llvm/test/LTO/X86/opt-level-size.ll
  llvm/test/tools/lto/opt-level.ll
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp
  llvm/tools/lto/lto.cpp

Index: llvm/tools/lto/lto.cpp
===
--- llvm/tools/lto/lto.cpp
+++ llvm/tools/lto/lto.cpp
@@ -28,14 +28,13 @@
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/raw_ostream.h"
 
-// extra command-line flags needed for LTOCodeGenerator
-static cl::opt
+static cl::opt
 OptLevel("O",
- cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
+ cl::desc("Optimization level. [-O0, -O1, -O2, -Os, -Oz or -O3] "
   "(default = '-O2')"),
  cl::Prefix,
  cl::ZeroOrMore,
- cl::init('2'));
+ cl::init("2"));
 
 static cl::opt
 DisableInline("disable-inlining", cl::init(false),
@@ -165,9 +164,15 @@
 CG->setAttr(attrs);
   }
 
-  if (OptLevel < '0' || OptLevel > '3')
-report_fatal_error("Optimization level must be between 0 and 3");
-  CG->setOptLevel(OptLevel - '0');
+  LLVMContext &Ctx = CG->getContext();
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getOptLevel(OptLevel)))
+CG->setOptLevel(*Result);
+
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getSizeLevel(OptLevel)))
+CG->setSizeLevel(*Result);
+
   CG->setFreestanding(EnableFreestanding);
 }
 
@@ -487,25 +492,19 @@
   CodeGen->setTargetOptions(InitTargetOptionsFromCodeGenFlags());
   CodeGen->setFreestanding(EnableFreestanding);
 
-  if (OptLevel.getNumOccurrences()) {
-if (OptLevel < '0' || OptLevel > '3')
-  report_fatal_error("Optimization level must be between 0 and 3");
-CodeGen->setOptLevel(OptLevel - '0');
-switch (OptLevel) {
-case '0':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::None);
-  break;
-case '1':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Less);
-  break;
-case '2':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Default);
-  break;
-case '3':
-  CodeGen->setCodeGenOptLevel(CodeGenOpt::Aggressive);
-  break;
-}
-  }
+  LLVMContext Ctx;
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getOptLevel(OptLevel)))
+CodeGen->setOptLevel(*Result);
+  else
+return nullptr;
+
+  if (ErrorOr Result = expectedToErrorOrAndEmitErrors(
+  Ctx, llvm::lto::getSizeLevel(OptLevel)))
+CodeGen->setSizeLevel(*Result);
+  else
+return nullptr;
+
   return wrap(CodeGen);
 }
 
Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -29,10 +29,11 @@
 using namespace llvm;
 using namespace lto;
 
-static cl::opt
-OptLevel("O", cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
-   "(default = '-O2')"),
- cl::Prefix, cl::ZeroOrMore, cl::init('2'));
+static cl::opt
+OptLevel("O",
+ cl::desc("Optimization level. [-O0, -O1, -O2, -Os, -Oz, or "
+  "-O3] (default = '-O2')"),
+ cl::Prefix, cl::ZeroOrMore, cl::init("2"));
 
 static cl::opt CGOptLevel(
 "cg-opt-level",
@@ -244,7 +245,10 @@
   Conf.OptPipeline = OptPipeline;
   Conf.AAPipeline = AAPipeline;
 
-  Conf.OptLevel = OptLevel - '0';
+  Conf.OptLevel =
+  check(llvm::lto::getOptLevel(OptLevel), "invalid optimization level");
+  Conf.SizeLevel =
+  check(llvm::lto::getSizeLevel(OptLevel), "invalid optimization level");
   Conf.UseNewPM = UseNewPM;
   switch (CGOptLevel) {
   case '0':
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -62,10 +62,11 @@
 
 using namespace llvm;
 
-static cl::opt
-OptLevel("O", cl::desc("Optimization level. [-O0, -O1, -O2, or -O3] "
-   "(d