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.
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.
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.
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/460Hiya Tommy that's a good find, it's.. binutils.
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.
For gcc supports, what’s the target here? I think currently only “inline assembly” + “assembler option forwarding” are supported.
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.
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.
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
Found in a google search, very valuable duscussion.