[LLVMdev] Predicated Vector Operations

Chandler Carruth chandlerc at google.com
Wed May 8 18:16:39 PDT 2013


On Thu, May 9, 2013 at 1:09 AM, Nadav Rotem <nrotem at apple.com> wrote:

> On May 8, 2013, at 4:00 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>
> Thinking that a masked store is conservatively a store of the full
> width of the store right?
>
>
> It depends on the optimization. Consider this example:
>
> masked_store(Val, Ptr , M)
> X = masked_load(Ptr, M2)
>
> If you assume that your store actually overwrites everything in that
> memory location then you don't need to load that memory location again. You
> can simply use the stored value. However, in our example X != Val.
>

I'm not sure I understand the full impact of this example, and I would like
to.

What are the desired memory model semantics for a masked store?
Specifically, let me suppose a simplified vector model of <2 x i64> on an
i64-word-size platform.

  masked_store(<42, 42>, Ptr, <true, false>)

Does this write to the entier <2 x i64> object stored at Ptr or not? Put
another way, consider:


  thread A:
    ...
    masked_store(<42, 42>, Ptr, <true, false>)
    ...

  thread B:
    ...
    masked_store(<42, 42>, Ptr, <false, true>)
    ...


Assuming there is no specific synchronization relevant to Ptr between these
two threads and their masked stores, does this form a data race or not?

>From a memory model perspective, if this does *not* form a data race, that
makes this tremendously more complex to implement, analyze, and optimize...
I'm somewhat hopeful that the desired semantics are for this to form a
datarace (and thus require synchronization when occurring in different
threads like this).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130509/6dd59fed/attachment.html>


More information about the llvm-dev mailing list