[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