similar to: Weird update_llc_test_checks behavior?

Hi Graham, I'll look into the patches next, but first some questions after reading the available white papers on the net. On 24 November 2016 at 15:39, Graham Hunter <Graham.Hunter at arm.com> wrote: > This complex constant represents the runtime value of `n` for any scalable type > `<n x m x ty>`. This is primarily used to increment induction variables and > generate

Hi, Looking at the language reference, vscale is an integer. This might pose a problem for fractional vscale. Furthermore, I believe that vscale is constant throughout the life of the program; so if RISC-V vscale can vary from instruction to instruction that may also be problematic unless you can just commit to one specific value of vscale. Also, I had a question about your table. Based

Hi, In RISC-V v-extension, operations could operate on a group of vector registers; we called it LMUL. If LMUL equals 2, it means we could operate on 2 vector registers at the same time. So, we have the following combinations of types. LMUL = 1 LMUL = 2 LMUL = 4 LMUL = 8 int64_t | vscale x 1 x i64 | vscale x 2 x i64 | vscale x 4 x i64 | vscale x 8

Hi all, On Tue, 7 Apr 2020 at 11:04, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 7 Apr 2020 at 09:30, Kai Wang via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > LMUL = 1 LMUL = 2 LMUL = 4 LMUL = 8 > > int64_t | vscale x 1 x i64 | vscale x 2 x i64 | vscale x 4 x i64 | vscale x 8 x i64

I've posted two patches on Phabricator to add support for VScale in LLVM. A brief recap on `vscale`: The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to create types such as `<vscale x 16 x i8>` for a scalable vector with at least 16 bytes. In the definition of the scalable type, `vscale` is specified as a positive constant of type integer that will only be

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)

Hi Luke, > was it intentional to leave out both jacob and myself? > [...] > if that was a misunderstanding or an oversight i apologise for raising it. It was definitely not my intention to be non-inclusive, my apologies if that seemed the case! > can i therefore recommend a change, here: > [...] > "This patch adds vscale as a symbolic constant to the IR, similar to >

On Tue, 7 Apr 2020 at 16:09, Renato Golin <rengolin at gmail.com> wrote: > > On Tue, 7 Apr 2020 at 12:51, Hanna Kruppe <hanna.kruppe at gmail.com> wrote: > > > 1. is LMUL always a multiple of ELEN? > > This happens to be true (at least in the current spec, disregarding > > some in-progress proposals) just because both are powers of two and > > the

On 08/01/2018 06:15 AM, Renato Golin wrote: > On Tue, 31 Jul 2018 at 23:46, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> In some sense, if you make vscale dynamic, >> you've introduced dependent types into LLVM's type system, but you've >> done it in an implicit manner. It's not clear to me that works. If we >> need dependent

On Tue, Oct 1, 2019 at 8:08 AM Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hello Jacob and Luke, > > First off, even if a dynamically changing vscale was truly necessary > for RVV or SV, this thread would be far too late to raise the question. > That vscale is constant -- that the number of elements in a scalable > vector does not change during program execution

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote: > On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I've posted two patches on Phabricator to add support for VScale in LLVM. Excellent! > > > > A brief recap on `vscale`: > > The scalable vector type in

On Tue, Oct 1, 2019 at 11:08 AM Graham Hunter <Graham.Hunter at arm.com> wrote: > Hi Luke, hi graham, thanks for responding in such an informative fashion. > > On 1 Oct 2019, at 09:21, Luke Kenneth Casson Leighton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > typedef vec4 float[4]; // SEW=32,LMUL=4 probably > > static vec4 globalvec[1024]; // vscale ==

On 26 November 2016 at 11:49, Paul Walker <Paul.Walker at arm.com> wrote: > Related to this I want to push this and related conversations in a different direction. From the outset our approach to add SVE support to LLVM IR has been about solving the generic problem of vectorising for an unknown vector length and then extending this to support predication. With this in mind I would

Hi David, Thanks for taking a look. > On 5 Jun 2018, at 16:23, dag at cray.com wrote: > > Hi Graham, > > Just a few initial comments. > > Graham Hunter <Graham.Hunter at arm.com> writes: > >> ``<scalable x 4 x i32>`` and ``<scalable x 8 x i16>`` have the same number of >> bytes. > > "scalable" instead of "scalable

Hi David, >>> The name "getSizeExpressionInBits" makes me think that a Value >>> expression will be returned (something like a ConstantExpr that uses >>> vscale). I would be surprised to get a pair of integers back. Do >>> clients actually need constant integer values or would a ConstantExpr >>> sufffice? We could add a ConstantVScale or

On 31 July 2018 at 21:10, David A. Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Hi David, >> >> Let me put the last two comments up: >> >>> > But we're trying to represent slightly different techniques >>> > (predication, vscale change) which need

On 07/31/2018 04:32 PM, David A. Greene via llvm-dev wrote: > Robin Kruppe <robin.kruppe at gmail.com> writes: > >>> Yes, the "is this supported" question is common. Isn't the whole point >>> of VPlan to get the "which one is better" question answered for >>> vectorization? That would be necessarily tied to the target. The

Hi David, Let me put the last two comments up: > > But we're trying to represent slightly different techniques > > (predication, vscale change) which need to be tied down to only > > exactly what they do. > > Wouldn't intrinsics to change vscale do exactly that? You're right. I've been using the same overloaded term and this is probably what caused the

On 28 November 2016 at 09:15, Alex Bradbury <asb at asbradbury.org> wrote: > The RISC-V vector proposal is still in the development stage, but it > will inevitably be vector length agnostic much like Hwacha. Krste gave > a talk about his proposal for the 'V' extension last year > <https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf> >

On 27 November 2016 at 13:59, Paul Walker <Paul.Walker at arm.com> wrote: > Thanks Renato, my takeaway is that I am presenting the design out of order. So let's focus purely on the vector length (VL) and ignore everything else. For SVE the vector length is unknown and can vary across an as yet undetermined boundary (process, library....). Within a boundary we propose making VL a