[LLVMdev] recognizing DTORs and vptr updates in LLVM.
Kostya Serebryany
kcc at google.com
Wed Mar 21 17:06:25 PDT 2012
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}
...
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/20120321/7697c5f7/attachment.html>
More information about the llvm-dev
mailing list