[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