gcc RVV vector support

[lkcl]

Does anyone know what the schedule is for RVV support in gcc? The LLVM port is being taken care of by Robin Kruppe, which is fantastic

gcc on the other hand, despite being the primary compiler for the linux kernel and so on, seems an anomalous omission, and whilst binutils is done I've not seen any word that a gcc port is underway.

L.

[Tommy Murphy]

Is this of any relevance?

https://github.com/riscv/riscv-gnu-toolchain/issues/460

[lkcl]

On Wednesday, September 25, 2019 at 2:19:53 AM UTC+8, Tommy Murphy wrote:
> Is this of any relevance?
>
>
> https://github.com/riscv/riscv-gnu-toolchain/issues/460

Hiya Tommy that's a good find, it's.. binutils. So at least support for the assembler, which allows people to experiment, write examples that test out ideas but actually confirm that they work, in combination with the spike rvv port.

I was able to do something like this for SV pretty much straight away without any modifications to scalar RISCV binutils, due to there being zero vector opcodes, just a CSR setup. That changed for SVPrefix and VBLOCK.

This one I found with a bit of digging:
https://gcc.gcc.gnu.narkive.com/7SbdP86B/risc-v-vector-extension-cauldron-discussion

Woo that looks like a lot of work. Adding new intrinsics, similar to how it's been done in LLVM, and so on.

It looks like the concept of full vectorised functions is missing from gcc.

I would be seriously tempted to temporarily route through LLVM by way of a GIMPL to LLVM converter, use the LLVM IR opportunistic full function vectorisation backend that Robin has been working on, and outputting GNU assembler as a second phase to get back into GNU tools.

L.

[lkcl]

On Wednesday, September 25, 2019 at 2:50:51 AM UTC+8, lkcl wrote:

Found this, it is for older versions:
https://dragonegg.llvm.org

I like iterative incremental approaches. Large tasks tend to take years to show progress and/or where early design mistakes were made. V daunting.

L.

[Tommy Murphy]

On Tuesday, 24 September 2019 19:50:51 UTC+1, lkcl wrote:

On Wednesday, September 25, 2019 at 2:19:53 AM UTC+8, Tommy Murphy wrote:
> Is this of any relevance?
>
>
> https://github.com/riscv/riscv-gnu-toolchain/issues/460

Hiya Tommy that's a good find, it's.. binutils. 

I read Jim's second post as implying that there was also gcc support but I didn't go digging and I guess I was mistaken?

 

[Jim Wilson]

On Tue, Sep 24, 2019 at 1:30 PM Tommy Murphy <tommy_...@hotmail.com> wrote:
> I read Jim's second post as implying that there was also gcc support but I didn't go digging and I guess I was mistaken?

I've been poking at rvv gcc support in my spare time, but considering
how many other things I'm working on, this means I haven't
accomplished much, and don't really have anything usable. Just a
bunch of ideas and experimental patches to test those ideas.

Jim

[Tommy Murphy]

Thanks Jim - that certainly clarifies matters for me. 

[Sober Liu]

For gcc supports, what’s the target here? I think currently only “inline assembly” + “assembler option forwarding” are supported.

Maybe we can define the program mode firstly, create test files in C and target assembly outputs? For me, I will be hesitate for many rvv instructions, whether to create intrinsics functions, or to create a rvv library (mixed C + asm).

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/c043b6a5-578d-483c-a7d7-f7bfc1500ab3%40groups.riscv.org.

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

---

[Andrew Waterman]

On Tue, Sep 24, 2019 at 5:26 PM Sober Liu <sob...@nvidia.com> wrote:

For gcc supports, what’s the target here? I think currently only “inline assembly” + “assembler option forwarding” are supported.

I believe the GCC support Jim's referring to is an intrinsics programming model.

There is also broad desire for an autovectorizer for RVV, but naturally that will be an heroic undertaking.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/MN2PR12MB315197F73B6933EB9D5F53B0AD870%40MN2PR12MB3151.namprd12.prod.outlook.com.

[lkcl]

On Wednesday, September 25, 2019 at 1:33:18 AM UTC+1, waterman wrote:

On Tue, Sep 24, 2019 at 5:26 PM Sober Liu <sob...@nvidia.com> wrote:

For gcc supports, what’s the target here? I think currently only “inline assembly” + “assembler option forwarding” are supported.

I believe the GCC support Jim's referring to is an intrinsics programming model.

There is also broad desire for an autovectorizer for RVV,

speaking to jacob (who is travelling at the moment) apparently robin's work in LLVM RVV is an opportunistic full-function autovectoriser, at the LLVM-IR level.  it's why i suggested the intermediary/incremental step diverting to LLVM via dragonegg.

but naturally that will be an heroic undertaking.

yehh *sigh* this is why the Khronos Group created SPIR-V in the first place, and why AMD hard-forked the entirety of LLVM.  they preserved the explicit full-functon vectorisation and predication provided by SPIR-V through to LLVM-IR, and kept those intrinsics throughout the LLVM-fork right through to the amdgpu (aka Radeon) assembly level.

i remember also a long time ago - i tried really hard to ask the person who'd done a gcc port to a parallel vector processor to recover the *only* hard drive in the world, sitting on a shelf - they weren't able to do so.  parallel vectorisation had been added there, and damnit what they'd done has been lost.

havng explicit support for vec2, vec3 and vec4 sub-vector types (and anything else that RVV and SV support) would be a really good start, as far as "low hanging fruit" is concerned.

apparently a quick google search does show that __attribute__ ((vector_size (16)) is already supported in gcc:

https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

and it does look like they've recognised that compatibility with OpenCL shuffle and shuffle2 is also important.

l.

[Cooper]

Hi Jim,

Do Sifive or SW TG have a roadmap for rvv gcc support? Or you want to implement all of it in your spare time?

[Jim Wilson]

On Wed, Sep 25, 2019 at 6:05 PM Cooper <bron...@gmail.com> wrote:
> Do Sifive or SW TG have a roadmap for rvv gcc support? Or you want to implement all of it in your spare time?

No and no.

Jim

[lkcl]

interestingly, in my enquiries to find funding for SV gcc support, i've encountered specialist companies that are being approached to handle RVV gcc (and LLVM) support.   business-to-business development costs do not precisely mesh with what NLNet, as a Charitable Foundation, because, well, they're a charity!  however if nothing else it was good to learn that there is actual interest.

given the underlying similarity between SV and RVV, jim (and palmer, kito, and andrew)), it *might* be possible to fund you - directly (not as employees: through direct donations which would be tax-deductible) - to add the Vectorisation support to gcc, *if* it also included SV at the back-end.

would that be of interest to any of you?  if so, do let me know (here or privately).

l.

[lkcl]

https://www.gnu.org/software/gcc/projects/tree-ssa/vectorization.html
https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

i found the above links: vector_size would map neatly to sub-vector-length, i think (with SV having only values 2, 3 and 4 there), and with auto-vectorisation already being present in gcc since 2003, i would imagine that the infrastructure already exists.

what's nice is that, according to the tree-ssa link above, gcc already has "conditional execution" which transforms "if x { c = a + b }" into PLUS_COND(a,b,x) which then allows predication to be applied as a parallel operation.

so this may actually turn out to be much more straightforward tthan appears at first sight.  altivec and x86 sse were the initial focus of attention for the autovectorisation efforts, it seems.

l.

[Kito Cheng]

Hi Luke:

GCC done some auto-vectorization supporting for ARM/SVE, you could try
with GCC 9 or trunk, and you can get testcase from GCC source tree[1].

For RVV, I believe we can leverage part of implementation from
ARM/SVE, but it still need lot of works :P

[1] https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite/gcc.target/aarch64/sve

[lkcl]

On Thursday, September 26, 2019 at 8:00:14 AM UTC+1, Kito Cheng wrote:

Hi Luke:

GCC done some auto-vectorization supporting for ARM/SVE, you could try
with GCC 9 or trunk, and you can get testcase from GCC source tree[1].

For RVV, I believe we can leverage part of implementation from
ARM/SVE, but it still need lot of works :P

:)

ah that makes a lot of sense.  i saw a lot of discussion / cross-over review between RVV, SV and SVE on the LLVM lists last year.  it makes sense that ARM would also focus on making sure that gcc had proper support for SVE, and with the similarity between the three it would not be that much extra work.

btw i spoke to the director of linaro several years ago and he explained that he *finally* managed to drum it into ARM that software support (BSPs, compilers) had to be *the* number one priority.  they finally got the message and set up linaro, where companies could then fund that and collaborate to get compiler support properly paid for.

l.

[1] https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite/gcc.target/aarch64/sve

[lkcl]

https://gcc.gcc.gnu.narkive.com/7SbdP86B/risc-v-vector-extension-cauldron-discussion

Found in a google search, very valuable duscussion.