[llvm-commits] [llvm] r41046 - /llvm/trunk/lib/VMCore/ConstantFold.cpp

[Chris Lattner]

On Aug 15, 2007, at 12:46 PM, Rafael Espindola wrote:

>> define void @_Z1g1S(%struct.S* noalias  %s) {
>> entry:        %tmp131415 = getelementptr %struct.S* %s, i32 0, i32  
>> 0          ; <i32 (...)***> [#uses=1]        %tmp16 = load i32  
>> (...)*** %tmp131415, align 4          ; <i32 (...)**> [#uses=1]
>>         %tmp26277 = load i32 (...)** %tmp16             ; <i32  
>> (...)*> [#uses=1]
>>         %tmp2829 = bitcast i32 (...)* %tmp26277 to void (% 
>> struct.S*)*           ; <void (%struct.S*)*> [#uses=1]
>>         tail call void %tmp2829( %struct.S* %s )
>>         ret void
>> }
>>
>> This still has the vtable dispatch (as required) but does not have  
>> any pointer
>> to method cruft left.
>
> Is it really required? Since S is passed by value, I think one can be
> sure that method called is S::f and not one from a class that inherits
> from S.

Very good point.  We would have to catch this in the GCC C++ front- 
end, which is independent of the LLVM stuff.

> Maybe a LLVM type definition should include support for defining that
> part of it is constant?

There are a variety of possible things we could extend LLVM to  
support better, but this one would be tricky.  Note that currently  
the optimizers don't even get the vtable for S at all, so it can't  
know what the real target is supposed to be.

It would be better if the C++ Front-end replaced the load of the  
vtable pointer (%tmp16) with a pointer to the constant vtable itself  
(which would require it to emit it into this translation unit or use  
an extern of it).  This would require LLVM to constant propagate the  
load of the actual function pointer form the vtable.

In practice, most people don't pass dynamic classes by value, so I  
don't think this actually occurs often...

-Chris