[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