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

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*").
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

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>

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/8f2b4eda/attachment.html>