[LLVMbugs] [Bug 13941] New: put unnamed_addr on virtual functions
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Thu Sep 27 01:59:31 PDT 2012
http://llvm.org/bugs/show_bug.cgi?id=13941
Bug #: 13941
Summary: put unnamed_addr on virtual functions
Product: clang
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: nlewycky at google.com
CC: llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk
Classification: Unclassified
Given this testcase:
void a(int);
struct Foo {
Foo();
~Foo();
virtual void foo();
};
Foo::Foo() { a(1); }
Foo::~Foo() { a(1); }
void Foo::foo() { a(1); }
Foo f;
we should be able to put unnamed_addr on all three functions. Currently, clang
does put them on constructors and destructors (and the vtable itself), but it's
also true that you can't take the address of a virtual function.
A virtual function pointer is a this-offset and an offset into the vtable. If
user code performs call a through a virtual function pointer, the
implementation needs to perform a new virtual dispatch in order to find the
actual function pointer.
As such, the only place the address gets written to is the vtable and there's
no legitimate way to observe it.
Remember that llvm will attempt to deduce unnamed_addr. Test with "clang -O2
x.cc -flto -S -o - -mllvm -disable-llvm-optzns".
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list