[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