[LLVMdev] Predicated Vector Operations

Eric Christopher echristo at gmail.com
Wed May 8 16:23:49 PDT 2013

On Wed, May 8, 2013 at 4:09 PM, 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.
> But Jim pointed out that anything merging loads would then need to
> merge the masks otherwise even if selection would work otherwise, any
> pass that merges loads would need to learn how to deal with masks. Not
> likely a deal killer since I don't think there are a lot of them, but
> it does explain why it's more work than having them pass through.
> I actually think that masks disrupt *everything* from alias analysis to
> SROA. If you ignore the mask bad thing will happen. You can't be
> conservative because you never know which way is 'conservative'. Should you
> assume that the mask is all zero or all one ?

I was thinking that they'd not be optimized, but you are correct that
it'll be invasive - examples are illuminating. :)

I'm less convinced it's everything, but it's definitely enough that
care should be taken before adding a mask field to load/stores. It
will involve quite a bit of work and the tradeoffs should be well
known; i.e. we should know that we're going to get something out of it
more so than we would if we added it as a "target independent
intrinsic" or some such. Maybe in the long run the ability to treat
vector converts+masked loads/stores as shuffles could be useful, I
don't know either.


More information about the llvm-dev mailing list