Date   

Re: LLVM with RVV intrinsic support

David Horner
 

Excellent.
Congratulations, and thank you!!

On Fri, May 14, 2021, 05:21 Kai Wang, <kai.wang@...> wrote:
Hi,

We would like to announce that the RISC-V V-extension v0.10 has been implemented in LLVM and the work has been committed upstream.


Barcelona Supercomputing Center (BSC), Codeplay Software, and SiFive have worked together to implement the RVV C API intrinsics for the V-extension and have implemented the foundation of CodeGen for Vector Length Specific (VLS) and Vector Length Agnostic (VLA) autovectorization for RISC-V. 


What we have committed to LLVM upstream:

* Support for the v0.10 V-extension specification

* Support for the RVV C intrinsics in https://github.com/riscv/rvv-intrinsic-doc/tree/v0.10

* Implement the draft vector calling convention in https://github.com/riscv/riscv-elf-psabi-doc/pull/171


Known issues:

* C intrinsics for Zvlsseg implementation is under discussion:

 - https://lists.llvm.org/pipermail/llvm-dev/2021-March/149518.html

* What type we should use for fp16 is under discussion:

 - https://github.com/riscv/rvv-intrinsic-doc/issues/18#issuecomment-818472454


RISC-V RVV example:

https://github.com/riscv/rvv-intrinsic-doc/blob/master/rvv_saxpy.c


Build command:

clang --target=riscv64-unknown-elf -march=rv64gcv0p10 -menable-experimental-extensions rvv_saxpy.c -o rvv_saxpy.elf



LLVM with RVV intrinsic support

Kai Wang
 

Hi,

We would like to announce that the RISC-V V-extension v0.10 has been implemented in LLVM and the work has been committed upstream.


Barcelona Supercomputing Center (BSC), Codeplay Software, and SiFive have worked together to implement the RVV C API intrinsics for the V-extension and have implemented the foundation of CodeGen for Vector Length Specific (VLS) and Vector Length Agnostic (VLA) autovectorization for RISC-V. 


What we have committed to LLVM upstream:

* Support for the v0.10 V-extension specification

* Support for the RVV C intrinsics in https://github.com/riscv/rvv-intrinsic-doc/tree/v0.10

* Implement the draft vector calling convention in https://github.com/riscv/riscv-elf-psabi-doc/pull/171


Known issues:

* C intrinsics for Zvlsseg implementation is under discussion:

 - https://lists.llvm.org/pipermail/llvm-dev/2021-March/149518.html

* What type we should use for fp16 is under discussion:

 - https://github.com/riscv/rvv-intrinsic-doc/issues/18#issuecomment-818472454


RISC-V RVV example:

https://github.com/riscv/rvv-intrinsic-doc/blob/master/rvv_saxpy.c


Build command:

clang --target=riscv64-unknown-elf -march=rv64gcv0p10 -menable-experimental-extensions rvv_saxpy.c -o rvv_saxpy.elf



Re: vector intrinsics for both RV32/RV64

Jim Wilson
 

On Wed, May 12, 2021 at 10:52 AM Guy Lemieux <guy.lemieux@...> wrote:
I’m starting a project where we want to use vector intrinsics and generate both 64b and 32b code (for RV64 and RV32).
It looks line the best way to do this right now is with GCC, where we were able to find up-to-date intrinsics for the v0.10 spec:

There is a gcc RVV port from SiFive, but it has been dormant for months, and is not being actively maintained at the moment.  You are better off using LLVM instead which is actively being worked on by multiple parties including SiFive.
Jim


Re: vector intrinsics for both RV32/RV64

Craig Topper
 

Hi Guy,

The latest LLVM git repository should have support for all intrinsics except segment load/store. The intrinsics missed the branch window for the LLVM 12 release, but should be in LLVM 13 when it is released in the second half of the year.

The riscv_vector.h header is autogenerated from other files when clang is built so you won’t find the header in the repository.

~Craig

On May 12, 2021, at 10:52 AM, Guy Lemieux <guy.lemieux@...> wrote:

Hi,

I’m starting a project where we want to use vector intrinsics and generate both 64b and 32b code (for RV64 and RV32).

It looks line the best way to do this right now is with GCC, where we were able to find up-to-date intrinsics for the v0.10 spec:


Is there a similar ability with LLVM? Vector support seems to be added, but no up to date intrinsics yet. This is the closest I could find, but it appears to be a bit out of date (vector spec 0.8) and only for RV32:


Sorry if this is an obvious question — I haven’t dug very deeply into this yet, but I thought this group would be able to give me better answers and save me a bit of time.

Thanks for any pointers.

Guy




vector intrinsics for both RV32/RV64

Guy Lemieux
 

Hi,

I’m starting a project where we want to use vector intrinsics and generate both 64b and 32b code (for RV64 and RV32).

It looks line the best way to do this right now is with GCC, where we were able to find up-to-date intrinsics for the v0.10 spec:


Is there a similar ability with LLVM? Vector support seems to be added, but no up to date intrinsics yet. This is the closest I could find, but it appears to be a bit out of date (vector spec 0.8) and only for RV32:


Sorry if this is an obvious question — I haven’t dug very deeply into this yet, but I thought this group would be able to give me better answers and save me a bit of time.

Thanks for any pointers.

Guy



Re: FYI: ARM vs. RISC-V vector extension conmparison

Bruce Hoult
 

Yeah. I posted this link to our reddit /r/riscv four weeks ago and made a few comments about it.


It was posted on Hacker News yesterday and both Chris BOOM! Celio and I made a few comments and replies:


I have since at the author's request pointed him at the current spec. 


Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.

In one HN comment I pointed out that while having scaled indexed addressing mode for your vectors can be nice, those extra bits in a fixed size opcode do come at a cost.

> On a quick reread, I see a complaint that's entirely due to how
> ARM represents indexed load operations, which has absolutely
> nothing to do with the vector ISA whatsoever.

Not exactly true.

If you can use fancy addressing modes in your vector loads and stores and you have a fixed length 32 bit opcode (as both Aarch64 and RISC-V do[1]) then specifying an index register and how much to shift it by is taking up an extra 7 bits of your opcode (5 for register number, 2 for shift amount) vs an instruction that just specifies a base pointer register.

That means one instruction is taking up the opcode space that could otherwise be used by 128 different instructions instead.

That means either your vector ISA has fewer instructions and capabilities than it otherwise could have, or else it is taking up a lot more of the overall opcode space.




On Sat, May 8, 2021 at 9:07 AM Allen Baum <allen.baum@...> wrote:

Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.


Re: FYI: ARM vs. RISC-V vector extension conmparison

Nick Knight
 

I guess the publicity doesn't hurt, but I do wish the author had considered our developments here (at riscv/riscv-v-spec). His material appears to derive from Patterson-Waterman's 2017 book (and sigarch blog-post), and the architecture has evolved a bit since.


On Fri, May 7, 2021 at 5:06 PM Allen Baum <allen.baum@...> wrote:

Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.


FYI: ARM vs. RISC-V vector extension conmparison

Allen Baum
 


Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding.


Re: GCC RISC-V Vector Intrinsic Instructions and #defines missing #defines

Kito Cheng
 

Hi Tony:

Could you create issues on github to track that?
https://github.com/riscv/riscv-gcc

Thanks :)

On Sat, Apr 10, 2021 at 9:14 AM Jim Wilson <jimw@sifive.com> wrote:

On Fri, Apr 9, 2021 at 3:40 PM Tony Cole via lists.riscv.org <tony.cole=huawei.com@lists.riscv.org> wrote:

I’m still new to RISC-V and the Vector extensions, so forgive me if I’ve missed something, the following have been fixed or noted before.

Also, am I sending this to the correct group for GCC RISC-V Vector Intrinsics? If not, who and how should I inform?

I would suggest filing an issue in the riscv/riscv-gnu-toolchain github tree. Put something like vector or rvv in the issue title to make it clear it is a vector related issue. The gcc support is not being actively worked on at the moment. LLVM is the current focus for all vector compiler support. Eventually someone may start working on the gcc vector support again. Meanwhile, bugs filed against the gcc vector support may or may not be fixed.

Jim


Re: GCC RISC-V Vector Intrinsic Instructions and #defines missing #defines

Jim Wilson
 

On Fri, Apr 9, 2021 at 3:40 PM Tony Cole via lists.riscv.org <tony.cole=huawei.com@...> wrote:

I’m still new to RISC-V and the Vector extensions, so forgive me if I’ve missed something, the following have been fixed or noted before.

Also, am I sending this to the correct group for GCC RISC-V Vector Intrinsics? If not, who and how should I inform?


I would suggest filing an issue in the riscv/riscv-gnu-toolchain github tree.  Put something like vector or rvv in the issue title to make it clear it is a vector related issue.  The gcc support is not being actively worked on at the moment.  LLVM is the current focus for all vector compiler support.  Eventually someone may start working on the gcc vector support again.  Meanwhile, bugs filed against the gcc vector support may or may not be fixed.

Jim


GCC RISC-V Vector Intrinsic Instructions and #defines missing #defines

Tony Cole
 

Hi all,

 

I’m still new to RISC-V and the Vector extensions, so forgive me if I’ve missed something, the following have been fixed or noted before.

 

Also, am I sending this to the correct group for GCC RISC-V Vector Intrinsics? If not, who and how should I inform?

 

 

 

I’m currently using: riscv32-unknown-elf-gcc (GCC) 10.1.0    (…/10.1.0–rvv-intrinsic-patch/bin/ riscv32-unknown-elf-gcc – version)

 

 

These (and probably others) don’t exist in the GCC compiler RISCV Vector intrinsics (the m8 versions):

 

        vint32m1_t vwredsum_vs_i16m8_i32m1 (vint32m1_t dst, vint16m8_t vector, vint32m1_t scalar, size_t vl);

        vint64m1_t vwredsum_vs_i32m8_i64m1 (vint64m1_t dst, vint32m8_t vector, vint64m1_t scalar, size_t vl);

 

They are listed in here: https://github.com/riscv/rvv-intrinsic-doc/blob/master/intrinsic_funcs/09_vector_reduction_functions.md

 

 

So, I’ve had to temporally change to (the m4 versions):

 

        vint32m1_t vwredsum_vs_i16m4_i32m1 (vint32m1_t dst, vint16m4_t vector, vint32m1_t scalar, size_t vl);
        vint64m1_t vwredsum_vs_i32m4_i64m1 (vint64m1_t dst, vint32m4_t vector, vint64m1_t scalar, size_t vl);

 

to get it to compile and work.

 

This may have already been fixed? Please let me know.

 

 

 

Also,

 

I was expecting to find some #defines for the rounding modes in riscv-vector.h, something like:

 

/* Vector Fixed-Point Rounding Mode Register vxrm settings

   Use with vwrite_csr(RVV_VXRM, RVV_VXRM_XXX) */

 

#define RVV_VXRM_RNU  (0) /* Round-to-nearest-up (add 0.5 LSB) */

#define RVV_VXRM_RNE  (1) /* Round-to-nearest-even */

#define RVV_VXRM_RDN  (2) /* Round-down (truncate) */

#define RVV_VXRM_ROD  (3) /* Round-to-add (OR bits into LSB, aka "jam") */

 

Tony Cole

CPU Consultant I RISC-V Cores, Bristol

E-mail: Tony.Cole@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件

 

 


Possible RISC-V Vector Instructions missing

Tony Cole
 

Hi Vector Team,

 

I’m new to RISC-V and the Vector extensions, so forgive me if I’ve missed something.

 

 

I have searched the specs, emails and git hub issues, but not found anything on this:

 

 

While writing some vector code using the vector intrinsics, I noticed some instructions missing that I expected to see:

 

I noticed there is no saturated reverse subtract version of vssub_vx, e.g. vsrsub_vx (or should it be vrssub_vx ?) and so no vsneg_v pseudo instructions

 

But there are the following integer/float reverse subtract instructions:

vrsub_vx

vfrsub_vf

 

and their pseudo instruction counterparts:

vneg_v

vfneg_v

 

For orthogonality there should be saturated versions of the above, but maybe there is not enough encoding space?

Or possibly remove vrsub_vx & vfrsub_vf to gain encoding space ??

 

Note: I wanted to use vsrsub_vx (to do vsneg_v), but instead achieved it by loading a vector with zero and performing vssub_vv.

 

Tony Cole

CPU Consultant I RISC-V Cores, Bristol

E-mail: Tony.Cole@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件

 


No vector task group meeting tomorrow

Krste Asanovic
 

I haven’t seen any burning issues come by, and am still trying to clean up spec.

So unless someone has agenda items, I’m canceling meeting tomorrow,
Krste


No vector TG meeting this week

Krste Asanovic
 

I’m still working on spec cleanup and I don’ t have any major outstanding issues to discuss, so will cancel the TG meeting this week.

Please bring up any burning issues on this mailing list,
Krste


Vector Task Group minutes from 2021/3/26 meeting

Krste Asanovic
 

Date: 2021/03/26
Task Group: Vector Extension
Chair: Krste Asanovic
Vice-Chair: Roger Espasa
Number of Attendees: ~10
Current issues on github: https://github.com/riscv/riscv-v-spec

A short meeting discussing only:

#545 Vector AMO Encoding

The group discussed the issue with vector AMO overlapping the desired
space for future scalar AMOs. The group agreed with the proposal to
leave vector AMOs out of the v1.0 specification to allow time to
revisit the encoding taking into account the needs of scalar AMOs.


Vector Task Group meeting Friday March 26

Krste Asanovic
 

We'll meet again in usual slot.

The main discussion topic will be #545. Please read the issue thread
on github.

Summary: The proposal is to move vector AMOs from their current
encoding to leave space for scalar subword AMOs, and to drop vector
AMOs from the base application processor vector profile (they were
already excluded from Zve* subset profiles). We'll rework the
vector AMO encoding, but not in path for v1.0 ratification.

Krste


Vector Extension Task Group Minutes 2021/03/19

Krste Asanovic
 

Date: 2021/03/19
Task Group: Vector Extension
Chair: Krste Asanovic
Vice-Chair: Roger Espasa
Number of Attendees: ~16
Current issues on github: https://github.com/riscv/riscv-v-spec

Issues discussed

#640 Bound on VLMAX/VLEN

Previously, we'd discussed making the upper bound on VLMAX part of
profile, but realization was that bound cannot be later increased in a
software-compatibile way without adding a new instruction, so is
effectively part of the ISA spec.

We discussed having the more general case of VLMAX being the bound,
but consensus was that having bound be a function of VLEN (<=65536)
was simpler to specify and had no great effect on range of supported
systems.

The extension to add independent control of data input size of
vrgather, proposed in #655, was briefly discussed, but this will not
be included in v1.0.

#651 expanding tail-agnostic to allow result values (masks only, or data)

The discussion was around expanding the set of allowable tail-agnostic
values to include the results of the computation.

The consensus was to expand this for mask register writes (except
loads), where only tail-agnostic behavior is required.

But support was not as clear for data register writes, where
tail-undisturbed behavior must be supported and where FP operations
require masking off exception flags even for tail-agnostic.

PoR is to expand mask register writes to allow results to be written
in tail, while continuing discussion on further relaxing for data
register writes.

#457 Ordering in vector AMOs

Current vector AMOs have no facility to order writes to the same
address, whereas indexed stores have an ordered option.

Discussion was on proposal to tie address-based ordering to the wd
(write result data) bit. One concern was that this seemed to hamper
some cases, including where software wanted the results but knew
addresses were disjoint. Providing ordering only on same address
would likely require slow implementation on out-of-order machine where
addresses can be produced out of order for different element groups.

Decision was to maintain PoR and consider post-v1.0 ways to support
ordered vector AMOs.


Next Vector TG Meeting, Friday March 19

Krste Asanovic
 

There are a few issues to discuss, so we’ll meet in the regular time slot on the calendar,
Krste


cancel Mar 12 Vector TG meeting

Krste Asanovic
 

I'm cancelling meeting again, as I still have not been able to clean
spec. I realize it will be more efficient for folks to wait for a
clean version for a complete read through. Few issues are being
reported/found, so I do not anticipate any substantive change.

One realization on issue #640 is that VLEN limit (<=64Kb) has to be
part of ISA spec, not just profile, to allow backwards compatibility.
Details on github issue.

One update is that RIOS Lab has agreed to help with architecture tests
and the SAIL model - thank you, RIOS!

Krste


cancel next Vector TG meeting, Friday March 5

Krste Asanovic
 

I'm still working through spec cleanup.

The list and github has been quiet, and I have no new issues to raise,
so I suggest we cancel this meeting and push out for a week.

Krste

101 - 120 of 696