llvm dev - Mar 2012 - [LLVMdev] recognizing DTORs and vptr updates in LLVM.

On Tue, Mar 20, 2012 at 1:50 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Mar 20, 2012, at 12:51 AM, Duncan Sands wrote:
>
> >>> Using instruction level metadata for this would be
appropriate.
>  However, I
> >>> also don't understand why a race on this is truly benign.
> >>
> >> It isn't, really; calling it "benign" is deceptive. 
It's just that
> >> storing a pointer which is equal to the existing pointer stored at
a
> >> given address almost always makes the optimizer/codegen generate
code
> >> which can't trigger the race in a way which visibly
misbehaves.
> >> Therefore, as a heuristic users apparently want ThreadSanitizer to
> >> ignore (or list separately) such races.
> >
> > 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).

Thanks!

--kcc

>  This would give us improved code quality, is straight-forward to reason
> about, is not "another knob" and would be a really easy for ASAN
to use.
>
> One issue is that TBAA is disabled in -O0 builds: I'd just make vtable
> TBAA information be produced when the optimizer is enabled or if ASAN is
> enabled.
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120321/7207a776/attachment.html>

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>