[LLVMdev] Adding masked vector load and store intrinsics

[Pete Cooper]

> On Oct 24, 2014, at 1:49 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Pete Cooper" <peter_cooper at apple.com>
>> To: "Nadav Rotem" <nrotem at apple.com>
>> Cc: dag at cray.com, llvmdev at cs.uiuc.edu
>> Sent: Friday, October 24, 2014 3:40:10 PM
>> Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics
>> 
>> On Oct 24, 2014, at 11:38 AM, Nadav Rotem < nrotem at apple.com > wrote:
>> 
>> I agree with the approach of adding target-independent masked memory
>> intrinsics. One reason is that I would like to keep the vectorizers
>> target independent (and use the target transform info to query the
>> backends). I oppose adding new first-level instructions because we
>> would need to teach all of the existing optimizations about the new
>> instructions, and considering the limited usefulness of masked
>> operations it is not worth the effort. I agree with this. They
>> should be target independent.
>> 
>> 
>> However, what types should be supported here? I haven’t looked in
>> detail, but from memory I believe AVX-512 masks 32-bit values, and
>> not bytes. Are we going to have an intrinsic which can handle any
>> vector type, or just <n x 32-bit> vectors, even at first?
> 
> I think you're confusing the IR types with the backend types. At the IR level, the masks are <n x i1> (one boolean per vector lane), the backend may represent this with a different type, but that's true of comparison results generally (they're often represented with different types in the backend), we already deal with that. Regarding the pointer type, it is irrelevant, we'll just cast to it from whatever the deal pointer type is.
Sorry, I should have been clearer.  I mean what types can the lanes be?  And assuming its not all types down to i8, how should we handle the illegal cases, or avoid creating them in the first place?

Thanks,
Pete
> 
> -Hal
> 
>> 
>> 
>> Also, given that the types of the vectors matter, it seems like we’re
>> going to need TTI anyway whenever we want to generate one of these,
>> or else we’ll end up generating an illegal version which has to be
>> scalarised in the backend.
>> 
>> 
>> Thanks,
>> Pete
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141024/4b22ad78/attachment.html>