================
@@ -19,20 +19,38 @@ namespace llvm {
// Visitor class that finds all indirect call.
struct PGOIndirectCallVisitor : public InstVisitor<PGOIndirectCallVisitor> {
std::vector<CallBase *> IndirectCalls;
+ std::vector<Instruction *> VTableAddrs;
PGOIndirectCallVisitor() = default;
void visitCallBase(CallBase &Call) {
if (Call.isIndirectCall())
- IndirectCalls.push_back(&Call);
+ if (Call.isIndirectCall()) {
+ IndirectCalls.push_back(&Call);
+
+ LoadInst *LI = dyn_cast<LoadInst>(Call.getCalledOperand());
----------------
minglotus-6 wrote:
It makes sense to improve usability. Updated description of option
`enable-vtable-value-profiling` in this commit for this purpose.
I wonder if clang is a better place to validate user options, considering
1) fwhole-program-vtables are clang options; and IRPGO looks at type metadata /
intrinsics generated by language frontend.
2) when vtable instrumentation (along with the optimization that uses it) is
rolled out to be default, a simple c++ binary which doesn't use class
inheritance could pick up the compiler flag change; and a warning is not
expected for this simple binary.
https://github.com/llvm/llvm-project/pull/66825
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
