[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