Change the cap on the amount of padding for each vtable to 32-byte (previously it was 128-byte)

[zhaomo]

Summary

We tested different cap values with a recent commit of Chromium. Our results show that the 32-byte cap yields the smallest binary and all the caps yield similar performance.
Based on the results, we propose to change the cap value to 32-byte.

[zhaomo]

• removed .arcconfig

[dberris]

llvm/lib/Transforms/IPO/LowerTypeTests.cpp

774–778

Is it possible to have a reference to the experiment results either through a link or a document or in a comment?

[zhaomo]

llvm/lib/Transforms/IPO/LowerTypeTests.cpp

774–778

How about a link to the email of the experiment results (http://lists.llvm.org/pipermail/llvm-dev/2018-July/124694.html)? Is the llvm-dev archive considered permanent?

[dberris]

llvm/lib/Transforms/IPO/LowerTypeTests.cpp

774–778

If it could be summarised somewhere in this file, it would be more permanent and less cryptic than the current comment. I can suggest a summary of the methodology, for example, even citing the trade-off being done. Something like:

Experiments with some large applications with a non-trivial number of dynamic types
have shown a binary size reduction of N% with virtually no measurable runtime overhead.
This padding used to be larger (128) and based on more recent experiments (see
<link to email or something in the LLVM docs/ directory>) we found that it could be
reduced to 32 and get significant binary size reductions with comparable runtime
performance.

Alternatively, if we can make the number a function of the cache line size (say, instead of 32 use the target's cache line size and derive something like 32 from it) which might/could explain why aligning to these numbers on those boundaries would not cause significant slowdowns but still have good binary size effects/properties. If I read the experiment results I can see that the platforms being built for/tested are 64-bit platforms with (I think) 64-byte cache lines.

[zhaomo]

Added more information about the experiments in the comment.

[pcc]

This looks fine if Dean is happy.

llvm/lib/Transforms/IPO/LowerTypeTests.cpp

775

Remove the word "now".

[dberris]

LGTM -- +1 to @pcc's suggestion on wording of the comment.

[zhaomo]

Updated the comment according to Peter's suggestion.

[pcc]

It looks like this patch causes the check-cfi tests to fail, can you please take a look?

[zhaomo]

Some tests failed because they did not expect the new layouts caused by the change to the padding cap. I modified those tests so that now they accept the new layouts.

.arcconfig

+{
+  "phabricator.uri" : "https://reviews.llvm.org/"
+}

llvm/lib/Transforms/IPO/LowerTypeTests.cpp

void LowerTypeTestsModule::buildBitSetsFromGlobalVariables(
   for (GlobalTypeMember *G : Globals) {
     GlobalVariable *GV = cast<GlobalVariable>(G->getGlobal());
     GlobalInits.push_back(GV->getInitializer());
     uint64_t InitSize = DL.getTypeAllocSize(GV->getValueType());
 
     // Compute the amount of padding required.
     uint64_t Padding = NextPowerOf2(InitSize - 1) - InitSize;
 
-    // Cap at 128 was found experimentally to have a good data/instruction
+    // Cap at 32 was found experimentally to have a good data/instruction
     // overhead tradeoff.
-    if (Padding > 128)
-      Padding = alignTo(InitSize, 128) - InitSize;
+    if (Padding > 32)
+      Padding = alignTo(InitSize, 32) - InitSize;
 
     GlobalInits.push_back(
         ConstantAggregateZero::get(ArrayType::get(Int8Ty, Padding)));
   }
   if (!GlobalInits.empty())
     GlobalInits.pop_back();
   Constant *NewInit = ConstantStruct::getAnon(M.getContext(), GlobalInits);
   auto *CombinedGlobal =
       new GlobalVariable(M, NewInit->getType(), /*isConstant=*/true,