[llvm-dev] PHI nodes for atomic variables

[Qiuping Yi via llvm-dev]

I used -O3. I will try MemorySSA analysis. Thanks!


Best regards,

Qiuping Yi
Institute Of Software
Chinese Academy of Sciences

On Thu, Feb 8, 2018 at 2:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> Let me try to help.
>
> On Thu, Feb 8, 2018 at 12:13 PM, Qiuping Yi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Thanks for your explanation.
>>
>> Do you mean that LLVM will not maintain the def-use chain for atomic
>> variables?
>>
> It is not a variable at the LLVM level.
> At the source level, it is a variable.
> At the LLVM IR level, it is lowered into memory operations.
> All of your operations were. None of them are in llvm registers.
> Some were then promoted or partially promoted into registers.
> (it looks like your output is -O1 or something and uses libstdc++ instead
> of libc++)
>
The loads are loads from a memory location.  It does not have any more data
> dependence info than your atomics.
>
> The phi you are seeing is not "LLVM giving you data dependence info".
>
> Memory is not in SSA form in LLVM and has no def use chains by default.
>
> If you want an SSA form for Memory, you would have to use the MemorySSA
> analysis.
>
>
>
>> So it is impossible to directly catch the fact that the load of x at the
>> statement 'data1 = x; ' dependents on data4 (because of the statement
>> x=data4 )?
>> If I want to get such information, may be the only solution is to
>> traverse all the predecessors of the statement 'data1 = x;'.
>>
>
> This will not work either in general.
>

>
>>
>>
>>
>> Best regards,
>>
>> Qiuping Yi
>> Institute Of Software
>> Chinese Academy of Sciences
>>
>> On Thu, Feb 8, 2018 at 3:11 AM, David Chisnall <
>> David.Chisnall at cl.cam.ac.uk> wrote:
>>
>>> On 8 Feb 2018, at 04:07, Qiuping Yi via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> >
>>> > I found that it only generated PHI node (%8 = phi i32 [ %4, %3 ], [
>>> %6, %5 ]) for non-atomic variable 'data2' but not for atomic variable x?
>>> Why?
>>>
>>> LLVM IR does not contain variables, it contains (immutable) registers.
>>> Some of these registers refer to memory locations and are usable with loads
>>> and stores.  The notion of ‘atomic’ doesn’t make sense in the context of a
>>> register, because registers are implicitly immutable (i.e. not updated, so
>>> atomic updates don’t make sense) and non-shared (so there’s nothing for
>>> accesses to them to be atomic with respect to).  As such, the atomic
>>> qualifier makes sense only with memory locations.  The memory address
>>> itself may be stored in a register, but updates to the location must be
>>> performed by loads and stores (or atomicrmw instructions).
>>>
>>> In the absence of any ordering constraints imposed by atomic memory
>>> operations (including fences), it is often safe to promote a sequence of
>>> loads and stores of a memory location to a single load / store pair with a
>>> sequence of registers storing temporary values.  This is allowed because,
>>> in the absence of something that establishes a happens-before relationship
>>> between threads, a thread is allowed to make writes to memory visible to
>>> other threads in any order.
>>>
>>> David
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/ba01190a/attachment.html>