[PATCH] D29701: ThinLTOBitcodeWriter: Write available_externally copies of VCP eligible functions to merged module.

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added a comment.

I assume these get dropped in the usual place where we eliminate available externally. Does VCP benefit from any of the other optimizations we would typically apply before that point (e.g. inlining)?



================
Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:284
+        if (!RT || RT->getBitWidth() > 64 || F->arg_empty() ||
+            !F->arg_begin()->use_empty())
+          return;
----------------
Add comment about what these are testing (I think I have correctly reasoned them out, but would be good to be explicit).


================
Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:297
+        if (auto *GVar = dyn_cast_or_null<GlobalVariable>(GV->getBaseObject()))
+          return HasTypeMetadata(GVar);
+        return false;
----------------
There are now comments about the eligible virtual funcs being added to the regular LTO, but I see there are no comments about the original condition here for putting a GVar in the regular LTO module - maybe add that or point to someplace that describes what we're doing.


================
Comment at: llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll:9
+
+; M0: @"g$84f59439b469192440047efc8de357fb" = external hidden constant [1 x i8*]{{$}}
+; M1: @"g$84f59439b469192440047efc8de357fb" = hidden constant [1 x i8*] [i8* bitcast (i64 (i8*)* @"ok$84f59439b469192440047efc8de357fb" to i8*)]
----------------
Where do the long hex strings come from in the names in this test?


https://reviews.llvm.org/D29701