llvm dev - Aug 2009 - [LLVMdev] [llvm-commits] [llvm] r79731 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp

On Aug 24, 2009, at 1:32 AM, Duncan Sands wrote:
> unfortunately, race detectors like helgrind don't like this kind of
> thing, and report it as a race.  Last time I asked about it I was
> told that fixing it would be too hard/expensive.
I know, and it's somewhat unfortunate.  However, this path is  
extremely hot in
LLC, and was significantly contended using only two threads.  I don't  
have a
non-contended solution offhand.
>>     VTs[VT.getSimpleVT().SimpleTy] = VT;
>> -    return &VTs[VT.getSimpleVT().SimpleTy];
>> +    sys::MemoryFence();
>
> I don't think this fence actually does anything useful unless
> users of the pointer do a fence before reading the contents
> of the pointer.  That said, I think alpha is the only platform
> where you have to worry about this kind of pointer vs pointee
> race.
I'm fairly sure that the only things that dereference into the array
are callers of this method, who dereference it through the returned
pointer.  The purpose of the fence is to guarantee that the valid has
been written before the pointer is returned to the caller.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090824/765ee056/attachment.html>

Hi Owen,
>>>     VTs[VT.getSimpleVT().SimpleTy] = VT;
>>> -    return &VTs[VT.getSimpleVT().SimpleTy];
>>> +    sys::MemoryFence();
>>
>> I don't think this fence actually does anything useful unless
>> users of the pointer do a fence before reading the contents
>> of the pointer.  That said, I think alpha is the only platform
>> where you have to worry about this kind of pointer vs pointee
>> race.
> 
> I'm fairly sure that the only things that dereference into the array
> are callers of this method, who dereference it through the returned
> pointer.  The purpose of the fence is to guarantee that the valid has
> been written before the pointer is returned to the caller.
as far as I know, using a memory barrier on CPU A has absolutely zero
effect on other CPUs unless they also do a memory barrier.  The fence
on CPU A causes it to publish information about its memory writes, and
pay attention to information published by other CPUs.  It doesn't force
other CPUs to pay attention to its info.  That's why I think this fence
is bogus: without a corresponding fence on readers of the value, it
doesn't do anything.

Ciao,

Duncan.