[LLVMdev] Missed devirtualization opportunities

John McCall rjmccall at apple.com
Mon Oct 11 23:29:48 PDT 2010


On Oct 11, 2010, at 10:06 PM, Nick Lewycky wrote:

> John McCall wrote:
>> On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote:
>>> A better way for a front-end to declare that vtbl-ptr-hacking is not
>>> expected and not supported is for it to emit llvm.invariant.start and
>>> llvm.invariant.end calls for it.
>> 
>> Some of us were talking about this apropos your earlier post.
>> @llvm.invariant.start/end aren't appropriate, because the memory *isn't*
>> invariant;  the user is totally allowed to destruct the object in-place and
>> create a new object there.
> 
> Emit an invariant.end before the destructor and invariant.start before the constructor.
> Are there cases where you can't tell (in Clang) whether the callee is the destructor?
> For example, it is forbidden to take the address of a destructor in C++.

It's true that constructors and destructors can only be called directly.  They can,
however, be called directly by a different function, which I may or may not inline.
I'm not certain how these intrinsics are supposed to pair up in that case, or what
happens to correctness if they don't.

John.



More information about the llvm-dev mailing list