llvm dev - Oct 2014 - [LLVMdev] Adding masked vector load and store intrinsics

> So %passthrough can *only* be undef or zeroinitializer?
No, it can be any value including undef and zeroinitializer.

We considered, while designing, zero and merge semantics and decided that merge
semantics is better because it covers zero semantics if you use zeroinitializer
in the %paththru.

-  Elena


-----Original Message-----
From: dag at cray.com [mailto:dag at cray.com] 
Sent: Friday, October 24, 2014 20:21
To: Demikhovsky, Elena
Cc: llvmdev at cs.uiuc.edu; Zaks, Ayal; Nadav Rotem <nrotem at apple.com>
(nrotem at apple.com); Chandler Carruth (chandlerc at google.com); Adam Nemet
(anemet at apple.com)
Subject: Re: Adding masked vector load and store intrinsics

"Demikhovsky, Elena" <elena.demikhovsky at intel.com> writes:
> %data = call <8 x i32> @llvm.masked.load (i32* %addr, <8 x i32>
> %passthru, i32 4, <8 x i1> %mask) where %passthru is used to fill the
> elements of %data that are masked-off (if any; can be zeroinitializer 
> or undef).
So %passthrough can *only* be undef or zeroinitializer?  If that's the case
it might make more sense to have two intrinsics, one that fills with undef and
one that fills with zero.  Using a general vector operand with a restriction on
valid values seems odd and potentially misleading.

Another option is to always fill with undef and require a select on top of the
load to fill with zero.  The load + select would be easily matchable to a target
instruction.

I'm trying to think beyond just AVX-512 to what other future architectures
might want.  It's not a given that future architectures will fill with zero
*or* undef though those are the two most likely fill values.

                             -David
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

"Demikhovsky, Elena" <elena.demikhovsky at intel.com> writes:
>> So %passthrough can *only* be undef or zeroinitializer?
> No, it can be any value including undef and zeroinitializer.
>
> We considered, while designing, zero and merge semantics and decided
> that merge semantics is better because it covers zero semantics if you
> use zeroinitializer in the %paththru.
But passthrough has to have some value, right, to know what to merge?
It must appear as an operand, correct?  I think this is good, I just
want to clarify.  :)

                             -David

>> So %passthrough can *only* be undef or zeroinitializer?
> No, it can be any value including undef and zeroinitializer.
>
> We considered, while designing, zero and merge semantics and decided 
> that merge semantics is better because it covers zero semantics if you 
> use zeroinitializer in the %paththru.
> But passthrough has to have some value, right, to know what to merge?
[Demikhovsky, Elena] Not necessarily. It may be "undef" on IR level.
When we don't care about value in masked-off lanes.
> It must appear as an operand, correct? 
[Demikhovsky, Elena] Yes.
> I think this is good, I just want to clarify.  :)
                             -David
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.