[LLVMbugs] [Bug 13227] New: Missing devirtualizations of final methods/classes

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13227

             Bug #: 13227
           Summary: Missing devirtualizations of final methods/classes
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


There are some cases where clang fails to devirtualize calls to methods that
are known to be final. The main cases are

* Type defining the method in not available in the expression:
struct A {
  virtual void f();
};
struct B : A {
  virtual void f();
};
struct C final : B {
};
void f(C* d) {
  static_cast<A*>(d)->f();
}

* Covariant return types:
struct A {
};
struct B {
};
struct C : public B, public A {
};
struct RA {
  virtual A *f();
};
struct RC final : public RA {
  virtual C *f();
};
A *f(RC *x) {
  return static_cast<RA*>(x)->f();
}

* Not a single expression:
struct A {
  virtual void f();
};
struct B final : public A {
  virtual void f();
};
void f(B *x) {
  A *y = x;
  y->f();
}

We could add special cases for them, but it is probably better if we figure out
a way to propagate the information so that LLVM can do the optimization. For
the first two cases, clang could just emit the vtable load from a known
constant and let LLVM optimize figuring out the function that is being called,
adjusting the this pointer, etc.

On the third example we would need to produce some intrinsic saying that the
vtable pointer in 'x' points to a known value so that llvm can const propagate
it.

-- 
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.