search for: d57504

...examples: ; Default fpenv fadd (isomorphic to the fadd instruction) %z = call double @llvm.fadd(%a, %b) ; Constrained fp add %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, metadata !fpexcept.strict) ; Constrained fp add with vector predication (https://reviews.llvm.org/D57504) %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) For constrained fp and VP, we only require a very restricted form of this. That is: - Tuples are only allowed on intrinsic function calls. -...

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><div>We propose introducing two new intrinsics: llvm.variable.length.load and llvm.variable.length.store.<br>We have implemented the infrastructure for defining and lowering these in this phabricator patch: <a

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,

...i1> mask works, then <4 x float> fadd with > a <1 x i1> mask, a <8 x float> fadd with a <2 x i1> mask, etc. should also > be possible overloads of the same intrinsic. > > Yep. Doing the same for standard vector IR is on the radar: > https://reviews.llvm.org/D57504#1380587. > > > So far, so good. A bit odd, when I think about it, but if hardware out > there has that capability, maybe this is a good way to encode it in IR > (other options might work too, though). The crux, however, is the > interaction with the dynamic vector length: is it in...

Hi, There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy to generalize PatternMatch/InstCombine/InstSimplify...

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 (

...to pass the full test-suite. In this backend we are providing vector intrinsic functions that cover almost fully the SX-Aurora vector ISA including masked vector instructions. It helps experienced programmers to write highly optimized code. 3. Merging LLVM-VP developments (https://reviews.llvm.org/D57504) for proper vectorization: We plan to use LLVM-VP as the core infrastructure for vectorization. (Saarland University is working on the LLVM-VP backend for VE). 4. Vectorization improvements: We welcome everybody who is interested in explicit vector length ISA and would like to develop and work on...

...113587.html http://lists.llvm.org/pipermail/llvm-dev/2018-April/122517.html http://lists.llvm.org/pipermail/llvm-dev/2018-June/123780.html There is also an ongoing discussion about vector predication, which is related but not depending on the scalable representation in IR: https://reviews.llvm.org/D57504 And the corresponding RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129791.html cheers, --renato

...get/set the active VL would be needed anyway. I imagine the resulting runtime value (instead of `vscale`) to then be used in loop indvar updates, address computations, etc. > ok, a link to that would be handy... let me see if i can find it... > what comes up is this: https://reviews.llvm.org/D57504 is that right? Yes, that's the one! Thanks, Sander > On 1 Oct 2019, at 14:42, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote: > > (readers note this, copied from the end before writing! > "Given that (2) is a very different use-case, I hope we can keep discuss...

...is style of vectorization > requires was shared on Phabricator recently: > https://reviews.llvm.org/D90343. > > Barcelona Supercomputer Centre shared a proof of concept for style 2 that > uses the Vector Predication Intrinsics proposed by Simon Moll (VP: > https://reviews.llvm.org/D57504, link to the POC: > https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi). In the past Arm has > shared an alternative implementation of 2 which predates the Vector > Predication intrinsics (https://reviews.llvm.org/D87056). > I think both are equally good. The third one seems a bit too res...

...A proof of concept of what this style of vectorization requires was shared on Phabricator recently: https://reviews.llvm.org/D90343. Barcelona Supercomputer Centre shared a proof of concept for style 2 that uses the Vector Predication Intrinsics proposed by Simon Moll (VP: https://reviews.llvm.org/D57504, link to the POC: https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi). In the past Arm has shared an alternative implementation of 2 which predates the Vector Predication intrinsics (https://reviews.llvm.org/D87056). The three vectorization approaches are all complementary and in the end we want to s...

...nerate a vector loop using VF (vscale x k) = whole vector register > width, followed by a scalar tail loop. > > 2) Generate only a vector loop with active vector length controlled by > the RISC-V `vsetvli` instruction and using Vector Predicated intrinsics > (https://reviews.llvm.org/D57504). (Of course, intrinsics come with > their own limitations but we feel it serves as a good proof of concept > for our use case.) We also extend the VPlan to generate VPInstructions > that are expanded using predicated intrinsics. > > We also considered a third hybrid approach of havi...

...the 'accumulator' operand to 'start value' because for fmul this is the start value of the reduction, rather than a value to which the fmul reduction is accumulated into. > Note that the LLVM-VP proposal also changes the way reductions are handled in IR (https://reviews.llvm.org/D57504). This could be an opportunity to avoid the "v2" suffix issue: LLVM-VP moves the intrinsic to the "llvm.vp.*" namespace and we can fix the reduction semantics in the progress. Thanks for pointing out Simon. I think for now we should keep this proposal separate from LLVM-VP as th...

Thanks @Robin and @Graham for giving some background on scalable vectors and clarifying some of the details! Apologies if I'm repeating things here, but it is probably good to emphasize the conceptually different, but complementary models for scalable vectors: 1. Vectors of unknown, but constant size throughout the program. 2. Vectors of changing size throughout the program. Where (2)

...uivalent code (and thus performance) with both approaches on a large codebase. We think predication is out of scope for the initial proposal and the right forum to discuss predication support in general are the related discussions on the list, the LLVM-VP proposal, [7] <https://reviews.llvm.org/D57504> and the round table at the Dev Meeting. We think our current proposal addresses the concerns raised previously, especially the concerns around the high cost of adding a new IR type, adding too many new intrinsics and generalising the approach to N dimensions. Unless there are any additional ma...

...9;accumulator' operand to 'start value' because for fmul this is the start value of the reduction, rather than a value to which the fmul reduction is accumulated into. >>> Note that the LLVM-VP proposal also changes the way reductions are handled in IR (https://reviews.llvm.org/D57504). This could be an opportunity to avoid the "v2" suffix issue: LLVM-VP moves the intrinsic to the "llvm.vp.*" namespace and we can fix the reduction semantics in the progress. >> Thanks for pointing out Simon. I think for now we should keep this proposal separate from LLVM...

...imon Moll via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> wrote: > > Hi, > > There is now an RFC for a roadmap to native vector predication > support in LLVM and a prototype implementation: > > https://reviews.llvm.org/D57504 > > The prototype demonstrates: > > -  Predicated vector intrinsics with an explicit mask and vector > length parameter on IR level. > -  First-class predicated SDNodes on ISel level. Mask and vector > length are value operands. > -  An incremental st...

On 05/04/2019 09:37, Simon Pilgrim via llvm-dev wrote: > On 04/04/2019 14:11, Sander De Smalen wrote: >> Proposed change: >> >> ---------------------------- >> >> In this RFC I propose changing the intrinsics for >> llvm.experimental.vector.reduce.fadd and >> llvm.experimental.vector.reduce.fmul (see options A and B). I also >> propose renaming

...scalable vectors: 1) Generate a vector loop using VF (vscale x k) = whole vector register width, followed by a scalar tail loop. 2) Generate only a vector loop with active vector length controlled by the RISC-V `vsetvli` instruction and using Vector Predicated intrinsics (https://reviews.llvm.org/D57504). (Of course, intrinsics come with their own limitations but we feel it serves as a good proof of concept for our use case.) We also extend the VPlan to generate VPInstructions that are expanded using predicated intrinsics. We also considered a third hybrid approach of having a vector loop with VF...

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog