[LLVMdev] Predicated Vector Operations

[Eric Christopher]

On Wed, May 8, 2013 at 1:48 PM, Nadav Rotem <nrotem at apple.com> wrote:
>
> On May 8, 2013, at 12:51 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> On Wed, May 8, 2013 at 11:32 AM, Nadav Rotem <nrotem at apple.com> wrote:
>
>
> On May 8, 2013, at 11:07 AM, dag at cray.com wrote:
>
>  It might be as simple as adding
> an IR-level predicated load and predicated store, I'm not sure.
>
>
> I think that selects on the inputs+outputs of instructions is a good
> abstraction, and I don't think that we need to add a mask operand to every
> LLVM IR instruction. However, we do need support for masked load/stores, and
> I think that we should implement them as target independent intrinsics. I
> don't want to change the generic LLVM IR Load/Store instructions because I
> don't want to modify all of the existing optimizations and I also don't want
> other users of the compiler to pay for this complexity.
>
>
> First statement: I'm not disagreeing. :)
>
> That said, wouldn't a new intrinsic necessarily require all of the
> passes to handle it? I'm just curious what you see the tradeoffs being
> here. I'd have though adding a mask to Load/Store that just isn't
> handled would be equivalent?
>
> -eric
>
>
> Hi Eric,
>
> Most passes won't have to handle the load/store intrinsics because they will
> look like a regular function calls that read/write from memory.  We don't
> need to change Reg2Mem or other passes that really can't do anything about
> masked memory operations.  On the other hand, If we do change the Load/Store
> instruction we will have to review all of our existing optimizations. For
> example, some optimizations assume that a store instruction actually writes
> and invalidates the memory location. However, this assumption is incorrect
> if we are using a mask.
>

I can almost see that, but how is the intrinsic any different from a
conservative width for stores/loads where they're not handled by an
optimization pass? I'm assuming I'm missing something here.

-eric