[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