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: unassignedb...@nondot.org
Reporter: leonardc...@google.com
CC: llvm-bugs@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
