aykevl added a comment.

Apparently there is also another patch that tries to do something very similar: 
D81223 <https://reviews.llvm.org/D81223>.

In D72404#3305275 <https://reviews.llvm.org/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 <https://reviews.llvm.org/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

Reply via email to