[LLVMdev] Predicated Vector Operations

[Chandler Carruth]

On Thu, May 9, 2013 at 6:04 PM, <dag at cray.com> wrote:

> Dan Gohman <dan433584 at gmail.com> writes:
>
> >     But I don't understand why defining this as not being a data race
> >     would complicate things. I'm assuming the mask values are
> >     statically known.  Can you explain a bit more?
> >
> > It's an interesting question for autovectorization, for example.
> >
> > Thread A:
> > for (i=0;i<n;++i)
> > if (i&1)
> > X[i] = 0;
> >
> > Thread B:
> > for (i=0;i<n;++i)
> > if (!(i&1))
> > X[i] = 1;
> >
> > The threads run concurrently without synchronization. As written,
> > there is no race.
>
> There is no race *if* the hardware cache coherence says so.  :) There
> are false sharing issues here and different machines have behaved very
> differently in the past.
>

Let's not conflate races with false sharing. They're totally different, and
false sharing is *not* what we're discussing here.


> The result entirely depends on the machine's consistency model.
>
> LLVM is a virtual machine and the IR should define a consistency model.
> Everything flows from that.  I think ideally we'd define the model such
> that there is no race in the scalar code and the compiler would be free
> to vectorize it.  This is a very strict consistency model and for
> targets with relaxed semantics, LLVM would have to insert
> synchronization operations or choose not to vectorize.


LLVM already has a memory model. We don't need to add one. ;] It's here for
reference: http://llvm.org/docs/LangRef.html#memmodel

Also, cache coherency is *not* the right way to think of a memory model. It
makes it extremely hard to understand and define what optimization passes
are allowed to do. I think LLVM's memory model does a very good job of this
for both scalar and vector code today. If you spot problems with it, let's
start a thread to address them. I suspect myself, Jeffrey, and Owen will
all be extremely interested in discussing any such issues.

The only thing that isn't in the model that is relevant here is something
that isn't in LLVM today -- masked loads and stores. And that was what
inspired my original question. =D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130512/8e5801e6/attachment.html>