[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