[LLVMdev] Missed devirtualization opportunities

John McCall rjmccall at apple.com
Wed Oct 13 17:26:12 PDT 2010


On Oct 13, 2010, at 5:09 PM, Kenneth Uildriks wrote:
> But I believe the language does allow "undefined behavior" if there's
> a use of pT when the pointed-to object isn't actually of type T.  It's
> an invalid use in that case, right?

Yes, but not for an arbitrary pointer which aliases pT.  That's why it's
a problem that llm.invariant is specified in terms of memory;  if we get
a pointer that we can prove aliases the invariant memory, we start
making assumptions we aren't allowed to make.

This C++ code might be well-formed, depending on what 'foo' does to its
argument:
  A *a = new A();
  a->~A();
  B *b = new (a) B();
  foo(b);
  a->bar();

AFAICT, your proposed IR will look like this (in pseudocode):
  %ptr = call i8* @operator new(...)
  %a = bitcast %ptr to %A*
  call void @A::A(%a)
  call void @llvm.invariant.begin(%a)
  call void @llvm.invariant.end(%a)
  call void @A::~A(%a)
  %b = bitcast %a to %B*
  call void @B::B(%b)
  call void @llvm.invariant.begin(%b)
  call void @foo(%b)
  %b.vtbl = gep %a, 1
  %vtbl = load %b.vtbl
  %fn.ptr = gep %vtbl, <offset>
  %fn = load %fn.ptr
  call %fn(%a)
  ...

What's stopping us here from (incorrectly) replacing %vtbl with B's vtable pointer?

John.



More information about the llvm-dev mailing list