[llvm-bugs] [Bug 49765] New: LLVM cannot devirtualize with MSVC-style RTTI

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Mar 29 15:46:19 PDT 2021


https://bugs.llvm.org/show_bug.cgi?id=49765

            Bug ID: 49765
           Summary: LLVM cannot devirtualize with MSVC-style RTTI
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: aeubanks at google.com, llvm-bugs at lists.llvm.org,
                    peter at pcc.me.uk

Consider this simple case when devirtualization should be possible after
inlining the constructor:
https://gcc.godbolt.org/z/osGe67s9b

struct Foo {
  Foo() {}
  virtual ~Foo() {}
  virtual void f() {}
  int x;
};
int main() {
  Foo *p = new Foo();
  p->f();
  delete p;
}

When RTTI data is disabled (/GR- / -fno-rtti-data), we cannot devirtualize the
call to Foo::f. We can optimize the vptr load, but the vtable alias inhibits
full devirtualization. See this instruction:
  call qword ptr [rip + "??_7Foo@@6B@"+8]

LLVM knows exactly which vtable we are loading from, but because of the MSVC
RTTI alias code pattern, it refuses to optimize away the load.

We should either make the optimize more aggressive, or find a better IR pattern
for MSVC-style RTTI.

Arthur had a patch to address this, but maybe it isn't sound:
https://reviews.llvm.org/D99240

-- 
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/20210329/2534092e/attachment-0001.html>


More information about the llvm-bugs mailing list