Clang does not add type metadata to available_externally vtables. When
choosing a summary to look at for virtual function definitions, make
sure we skip summaries for any available externally vtables as they will
not describe any virtual function functions, which are only summarized
in the presence of type metadata on the vtable def. Simply look for the
corresponding strong def's summary.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 40242 Build 40339: arc lint + arc unit
Event Timeline
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp | ||
---|---|---|
845 | The code below doesn't go well along with the comment. For example it allows having multiple linkonce_odr/weak_odr summaries and multiple ones with available_externally linkage. | |
848–849 | Can we use single find_if instead of lines 856-871 for the sake of simplicity? auto I = llvm::find_if( P.VTableVI.getSummaryList(), [&](const std::unique_ptr<GlobalValueSummary> &Summary) { return !GlobalValue::isAvailableExternallyLinkage(Summary->linkage()); }); |
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp | ||
---|---|---|
845 | That is the intent of both the code and the comment, which might not be written very clearly. The code previously allowed multiple weak/linkonce odr, and now should also allow for multiple available_externally. Hence the comment "all but one must be available_externally" - because we can have multiple available externally but only one external linkage. Does that clarify things, or do you have alternate wording in mind that could be clearer? Now that I think about it, this code should probably also proactively guard against the type of situation encountered and handled in D28411 and D67322 of same-named locals in same-named files compiled without enough distinguishing path. In that case we should not assert and just be conservatively correct. The easiest way to do that is to simply return false from this routine if that situation is encountered. I will add that handling. | |
848–849 | Good idea, will change. |
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp | ||
---|---|---|
845 | Is it allowed having weak_odr + linkonce_odr + available_externally in P.VTableVI.getSummaryList()? If yes (I think it should be) than all but one must be available_externally is misleading. If not the code itself should be changed. |
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp | ||
---|---|---|
845 | Yes, that is a valid combination. I have changed the comment and the code. I made the lookup of the first non-available externally into a loop so I can also check for the case of multiple locals vtables with the same guid owing to not enough distinguishing path and same source file name (handled conservatively by returning false), and added a test case. | |
848–849 | Changed as described above - use a loop so I can also look for the clashing local guid case. |
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp | ||
---|---|---|
874 | Hi Theresa! |
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp | ||
---|---|---|
874 | Thanks for the report and repro. I will take a look today. Conceptually it seems like a simple fix of invoking getBaseObject() on the summary is needed at some point in this loop. |
The code below doesn't go well along with the comment. For example it allows having multiple linkonce_odr/weak_odr summaries and multiple ones with available_externally linkage.