similar to: [RFC] Vector Predication

Hi, On 1/31/19 11:20 PM, Jacob Lifshay wrote: > We're in-progress designing a RISC-V extension > (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) > that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x float>> > where each predicate bit masks out a whole short vector. We're using > this extension

On 2/2/19 1:39 AM, Luke Kenneth Casson Leighton wrote: > > > On Friday, February 1, 2019, Simon Moll <moll at cs.uni-saarland.de > <mailto:moll at cs.uni-saarland.de>> wrote: > > We could untie the mask length from the data length: > >   %result = call <scalable 4 x float> > @llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4

On Thu, Feb 7, 2019, 09:21 Simon Moll <moll at cs.uni-saarland.de> wrote: > > On 2/7/19 6:08 PM, David Greene wrote: > > Jacob Lifshay <programmerjake at gmail.com> writes: > > > >> So it would be handy for the vector length on evl intrinsics to be in > >> units of the mask length so we don't have to pattern match a division > >> in the

Jacob Lifshay <programmerjake at gmail.com> writes: > So it would be handy for the vector length on evl intrinsics to be in > units of the mask length so we don't have to pattern match a division > in the backend. We could have 2 variants of the vector length > argument, one in terms of the data vector and one in terms of the mask > vector. we could legalize the mask

On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Simon Moll <moll at cs.uni-saarland.de> writes: > > > You are referring to the sub-vector sizes, if i am understanding > > correctly. I'd assume that the mask sub-vector length always has to be > > either 1 or the same as the data sub-vector length. For example,

On Mon, 4 Feb 2019 at 22:04, Simon Moll <moll at cs.uni-saarland.de> wrote: > On 2/4/19 9:18 PM, Robin Kruppe wrote: > > > > On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Simon Moll <moll at cs.uni-saarland.de> writes: >> >> > You are referring to the sub-vector sizes, if i am

On Thu, Jan 31, 2019 at 4:05 PM Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Do such architectures frequently have arithmetic operations on the mask registers? (i.e. can I reasonable compute a conservative length given a mask register value) If I can, then having a mask as the canonical form and re-deriving the length register from a mask for a sequence of

Hi, On 1/31/19 8:17 PM, Philip Reames wrote: > > On 1/31/19 11:03 AM, David Greene wrote: >> Philip Reames <listmail at philipreames.com> writes: >> >>> Question 1 - Why do we need separate mask and lengths? Can't the >>> length be easily folded into the mask operand? >>> >>> e.g. newmask = (<4 x i1>)((i4)%y & (1 <<

Philip Reames <listmail at philipreames.com> writes: > Question 1 - Why do we need separate mask and lengths? Can't the > length be easily folded into the mask operand? > > e.g. newmask = (<4 x i1>)((i4)%y & (1 << %L -1)) > and then pattern matched in the backend if needed I'm a little concerned about how difficult it will be to maintain enough

Simon Moll <moll at cs.uni-saarland.de> writes: >> How will existing passes be taught about the new intrinsics? For >> example, what would have to be done to instcombine to teach it about >> these intrinsics? Let's suppose every existing operation had an >> equivalent masked intrinsic. Would it be easier to teach all of the >> passes about them or would

On 2/5/19 1:27 AM, Philip Reames via llvm-dev wrote: > > On 1/31/19 4:57 PM, Bruce Hoult wrote: >> On Thu, Jan 31, 2019 at 4:05 PM Philip Reames via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> Do such architectures frequently have arithmetic operations on the >>> mask registers?  (i.e. can I reasonable compute a conservative >>> length

Hi all, During the review of https://reviews.llvm.org/D65997 an issue was revealed, which relates to the decision of how compiler should represents constrained floating point operations. If a floating point operation requires rounding mode or exception behavior different from the default, it should be represented by constrained intrinsic (

Adam Nemet via llvm-dev <llvm-dev at lists.llvm.org> writes: > I spent some time chatting with Adam about this and have a better > understanding of his concerns here. It seems to me that if having > masking intrinsics is the long-term solution we want, we should do > that now (for add and sub) rather than building arbitrary matrix > layout info into

On 2/5/19 12:06 PM, Bruce Hoult wrote: > On Tue, Feb 5, 2019 at 1:23 AM Simon Moll <moll at cs.uni-saarland.de> wrote: >> I think this is the usual mixup of AVL and MVL. >> >> AVL: is part of the predicate and can change between vector operations >> just like a mask can (light weight). >> >> MVL: Is the physical vector register length and can be

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic

> You have similar problems with https://reviews.llvm.org/D79100 The new revision D79100<https://reviews.llvm.org/D79100> solves your comment 1), and I don't think your comments2) and 3) apply as there are no vendor specific intrinsics involved at all here. Just to quickly discuss the optimisation pipeline, D79100<https://reviews.llvm.org/D79100> is a small extension for the

Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches. And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing first like the LV

On 11/6/20 12:39 PM, Sjoerd Meijer wrote: Hello Simon, Thanks for your replies, very useful. And yes, thanks for the example and making the target differences clear: ; Some examples: ; RISC-V V & VE(*): ; %mask = (splat i1 1) ; %evl = min(256, %n - %i) ; MVE/SVE : ; %mask = get.active.lane.mask(%i, %n) ; %evl = call @llvm.vscale() ; AVX: ; %mask = icmp (%i + (seq

On 11/6/20 8:49 AM, Roger Ferrer Ibáñez wrote: Hi Sjoerd, Trying to remember how everything fits together here, but could get.active.lane.mask not create the %mask of the VP intrinsics? Or in other words, in the vectoriser, who's producing the %mask and %evl that is consumed by the VP intrinsics? I'm not sure what would be the best way here. I think about the Loop Vectorizer. I imagine

Hi, I abandoned that approach and followed Eli's suggestion, see somewhere earlier in this thread, and emit an intrinsic that represents/calculates the active mask. I've just uploaded a new revision for D79100 that implements this. Cheers. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 18 May 2020 13:32 To: Sjoerd Meijer <Sjoerd.Meijer at