[LLVMbugs] [Bug 23195] New: Failure to exploit final modifier for pointer to member devirtualization

[bugzilla-daemon at llvm.org]

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

            Bug ID: 23195
           Summary: Failure to exploit final modifier for pointer to
                    member devirtualization
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

We appear to be failing to devirtualize a pointer-to-member call when we know
that the type of the receiver is a final class.

(NOTE: This bug report is based on data collected on a ToT build in early
March.  I have not confirmed that this still applies to ToT today.)

I originally noted this when writing a toy interpreter.  Here's a simplified
bit of code pulled from that project:
struct Interpreter final {
  typedef void (Interpreter::*BytecodeFuncType)(void *);
  BytecodeFuncType BytecodeFuncs[NumBytecodes] = { ...  };

  void dispatch_next(void* stack){
    BytecodeFuncType NextFunc = BytecodeFuncs[bytecode[current_index]];
    current_index++;
    (this->*NextFunc)(stack);
  }
};

The important part is this line:
(this->*NextFunc)(stack);

This is calling a pointer-to-member function where the receiver type is
statically known.  In particular, we know that "this" is a static type of
Interpreter and that, because of the final annotation, there are no other
possible dynamic types.

We emit LLVM IR that looks like this (after -O3):
  %13 = load { i64, i64 }* %arrayidx3.i, align 8, !tbaa !10
  %.fca.0.extract.i = extractvalue { i64, i64 } %13, 0
  %.fca.1.extract.i = extractvalue { i64, i64 } %13, 1
  %14 = bitcast %struct.Interpreter* %this to i8*
  %15 = getelementptr inbounds i8* %14, i64 %.fca.1.extract.i
  %this.adjusted.i = bitcast i8* %15 to %struct.Interpreter*
  %16 = and i64 %.fca.0.extract.i, 1
  %memptr.isvirtual.i = icmp eq i64 %16, 0
  br i1 %memptr.isvirtual.i, label %memptr.nonvirtual.i, label
%memptr.virtual.i

memptr.virtual.i:                                 ; preds =
%_ZNSt6vectorIlSaIlEE9push_backEOl.exit
  %17 = bitcast i8* %15 to i8**
  %vtable.i = load i8** %17, align 8, !tbaa !11
  %18 = add i64 %.fca.0.extract.i, -1
  %19 = getelementptr i8* %vtable.i, i64 %18
  %20 = bitcast i8* %19 to void (%struct.Interpreter*, %"class.std::vector"*)**
  %memptr.virtualfn.i = load void (%struct.Interpreter*,
%"class.std::vector"*)** %20, align 8
  br label %_ZN11Interpreter13dispatch_nextERSt6vectorIlSaIlEE.exit

memptr.nonvirtual.i:                              ; preds =
%_ZNSt6vectorIlSaIlEE9push_backEOl.exit
  %memptr.nonvirtualfn.i = inttoptr i64 %.fca.0.extract.i to void
(%struct.Interpreter*, %"class.std::vector"*)*
  br label %_ZN11Interpreter13dispatch_nextERSt6vectorIlSaIlEE.exit

_ZN11Interpreter13dispatch_nextERSt6vectorIlSaIlEE.exit: ; preds =
%memptr.virtual.i, %memptr.nonvirtual.i
  %21 = phi void (%struct.Interpreter*, %"class.std::vector"*)* [
%memptr.virtualfn.i, %memptr.virtual.i ], [ %memptr.nonvirtualfn.i,
%memptr.nonvirtual.i ]
  tail call void %21(%struct.Interpreter* %this.adjusted.i,
%"class.std::vector"* dereferenceable(24) %stack)
  ret void

The virtual dispatch path of this control flow is impossible. Similarly, all of
the this adjustment code is unnecessary.

-- 
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/20150410/17ffb49c/attachment.html>