[PATCH] [GlobalMerge] Take into account minsize attribute of global users' parents.

Ahmed Bougacha ahmed.bougacha at gmail.com
Wed Jun 3 19:06:27 PDT 2015


REPOSITORY
  rL LLVM

================
Comment at: lib/CodeGen/GlobalMerge.cpp:201
@@ -193,3 +200,3 @@
   // If we want to just blindly group all globals together, do so.
   if (!GlobalMergeGroupByUse) {
     BitVector AllGlobals(Globals.size());
----------------
qcolombet wrote:
> Shouldn’t the size option affect this setting?
I'm not sure how, because without users, there's no minsize attribute to look at.

It shouldn't matter anyway, as this is mostly an option for testing (to get the old GlobalMerge behavior back).

================
Comment at: lib/Target/ARM/ARMTargetMachine.cpp:350
@@ -349,2 +349,3 @@
     // tricky when doing code gen per function.
-    addPass(createGlobalMergePass(TM, 127));
+    bool OnlyOptimizeForSize = TM->getOptLevel() < CodeGenOpt::Aggressive;
+    addPass(createGlobalMergePass(TM, 127, OnlyOptimizeForSize));
----------------
qcolombet wrote:
> Just for the record, a quick comment.
> 
> I am not very fond of the “if not aggressive” then do size only, but based of our offline discussion I agree this is pretty much what we do in the pass manager when creating other passes (like loop unswitch).
> 
> Anyhow, I do not have a better alternative.
> 
I don't like it either, but I also couldn't come up with a better way ;)

================
Comment at: test/CodeGen/AArch64/global-merge-ignore-single-use-minsize.ll:39
@@ +38,2 @@
+; CHECK-DAG: .zerofill __DATA,__bss,_m2,4,2
+; CHECK-DAG: .zerofill __DATA,__bss,_n2,4,2
----------------
qcolombet wrote:
> In the previous test case, you have a clear separation between the globals used in minsize functions and the ones used in non-minsize function.
> 
> Could you make another test case that mixes both?
> I.e.,
> G1
> G2
> G3
> 
> minsizefunc {
> G1
> G3
> }
> 
> non-minsizefunc {
> G1
> G2
> }
Done.

http://reviews.llvm.org/D10054

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list