[LLVMdev] recognizing DTORs and vptr updates in LLVM.

Chris Lattner clattner at apple.com
Thu Mar 22 14:22:53 PDT 2012


On Mar 21, 2012, at 5:06 PM, Kostya Serebryany wrote:

> Chris, is this how the tbaa for vtable loads/stores should look like? 
> 
> Metadata: 
> !0 = metadata !{metadata !"vtable pointer", metadata !1}
> !1 = metadata !{metadata !"omnipotent char", metadata !2}
> !2 = metadata !{metadata !"Simple C/C++ TBAA", null}

char*'s can't point to vtables, so I think that "Simple C/C++ TBAA" should be the parent of vtables.  Otherwise, looks great.

-Chris

> ...
> 
> Load: 
>   %0 = bitcast %struct.A* %a to void (%struct.A*)***
>   %vtable = load void (%struct.A*)*** %0, align 8, !tbaa !0
> 
> Store: 
>   %0 = getelementptr inbounds %struct.B* %this, i64 0, i32 0, i32 0
>   store i32 (...)** bitcast (i8** getelementptr inbounds ([5 x i8*]* @_ZTV1B, i64 0, i64 2) to i32 (...)**), i32 (...)*** %0, align 8, !tbaa !0
> 
> --kcc 
> 
> 
> 
> 
> 
> On Wed, Mar 21, 2012 at 12:57 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Mar 21, 2012, at 11:53 AM, Kostya Serebryany wrote:
> 
>> > The gcc Ada front-end does this too, in quite a range of situations.  For
>> > example multiple threads racily initialize a pointer variable, but they all
>> > initialize to the same value.  The various valgrind based race detection
>> > tools all complain about this, which makes them much less useful than they
>> > might be for Ada.
>> 
>> FWIW, after thinking about this for awhile, I realize that we already have the tools to handle this: TBAA.
>> 
>> It would be general goodness for clang to emit VTable loads and stores in their with their own TBAA type class (one that does not even alias "char*").
>> 
>> Indeed, sounds very nice.
>> I'll try to make a patch that adds TBAA metadata to VTable loads (unless someone else knows how to do it off the top of his head). 
>> 
> 
> Sounds great, thanks Kostya,
> 
> -Chris
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120322/9a5c4b1c/attachment.html>


More information about the llvm-dev mailing list