[LLVMdev] Predicated Vector Operations

Nadav Rotem nrotem at apple.com
Wed May 8 13:48:32 PDT 2013


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. 

Thanks,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/80b3906b/attachment.html>


More information about the llvm-dev mailing list