[llvm-bugs] [Bug 50048] New: Support for Relative VTables C++ ABI in Whole Program Devirtualization
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Apr 20 16:20:58 PDT 2021
https://bugs.llvm.org/show_bug.cgi?id=50048
Bug ID: 50048
Summary: Support for Relative VTables C++ ABI in Whole Program
Devirtualization
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Global Analyses
Assignee: unassignedbugs at nondot.org
Reporter: leonardchan at google.com
CC: llvm-bugs at lists.llvm.org
Currently, whole program devirtualization doesn't actually take effect on
vtables built under the relative vtables ABI. The `DevirtModule` pass is still
run, but it doesn't detect any vtable call slots because the transformation
attempts to pattern match against instructions that look like a load into the
vtable (ie. bitcasts, loads, GEPs).
More specifically, within `DevirtModule::run`, virtual function call sites are
added through a call to `DevirtModule::scanTypeTestUsers`, which eventually
calls `findLoadCallsAtConstantOffset`. This function attempts to check if calls
made to a vptr are done through bitcasts, loads, or GEPs. Under RV, loads to
the vtable are instead made with a call to the intrinsic `llvm.load.relative`.
Because we don't currently check for this intrinsic, no call sites are
recorded, and the pass doesn't make any transformations. This means that
devirtualization won't actually take place under RV.
A first step would be to add the proper checks for supporting RV in this case.
It's likely that we will run into other build/runtime issues after this though
since there may be other assumptions made about the vtable layout or how it's
accessed within WPD.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210420/492c7d22/attachment.html>
More information about the llvm-bugs
mailing list