[llvm-dev] PHI nodes for atomic variables

[Qiuping Yi via llvm-dev]

Thanks for your explanation.

Do you mean that LLVM will not maintain the def-use chain for atomic
variables?
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;'.



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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/89cc461c/attachment.html>