[LLVMbugs] [Bug 23521] New: unnecessary emission of vtable etc when clang sees an (ununsed) inline key function definition

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed May 13 17:01:06 PDT 2015


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

            Bug ID: 23521
           Summary: unnecessary emission of vtable etc when clang sees an
                    (ununsed) inline key function definition
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider:

  struct S { virtual void f(); };
  inline void S::f() {}

Clang (and GCC and EDG) at -O0 emits a definition for S::f and for S's vtable,
type info and so on. This is unnecessary (and removed at -O1 and above).

Instead, we could do the following:

 * When we see a definition of an inline key function, treat the class as if it
had no key function, and in particular don't force anything to be emitted and
emit the vtable lazily and on demand.
 * When the (vtable, type info, ...) is emitted, ensure we also emit the inline
key function.
 * When we emit an inline key function, also trigger the emission of the
associated class data (vtable etc.)


[This causes a -O0 modules bootstrap to fail right now: clang-format imports a
module that contains ASTMatchers.h, which define a number of classes with
inline key functions. Those key functions in turn use other non-inline
functions in that same header. Thus emitting the key functions gives
clang-format a link dependency on ASTMatchers.o, which is not linked into
clang-format.]

-- 
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/20150514/e51c79f2/attachment.html>


More information about the llvm-bugs mailing list