(original) (raw)
Cool. Sounds good.On Oct 24, 2014, at 1:53 PM, Hal Finkel <hfinkel@anl.gov> wrote:----- Original Message -----From: "Pete Cooper" <peter\_cooper@apple.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: dag@cray.com, llvmdev@cs.uiuc.edu, "Nadav Rotem" <nrotem@apple.com>
Sent: Friday, October 24, 2014 3:51:02 PM
Subject: Re: \[LLVMdev\] Adding masked vector load and store intrinsics
On Oct 24, 2014, at 1:49 PM, Hal Finkel < hfinkel@anl.gov > wrote:
----- Original Message -----
From: "Pete Cooper" < peter\_cooper@apple.com >
To: "Nadav Rotem" < nrotem@apple.com >
Cc: dag@cray.com , llvmdev@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@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 vectors, even at first?
I think you're confusing the IR types with the backend types. At the
IR level, the masks are (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?
You're correct, we'd use TTI to avoid creating illegal cases. If we do end up with an illegal case, it will need to be scalarized (which should always be possible). Syntactically, all basic vector types should be allowed.
Pete
-Hal
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@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory