V extension #75
Comments
|
GCC trunk doesn't support draft extensions. V is in the very final ("weeks"? There's a big RISC-V conference in early December that may help push things along) stages of support, but it's not final so it can't go in GCC trunk. There are various forks in vendor chains (sifive, allwinner/alibaba) that support some given draft of V, but it's kind of a messy since there is no silicon at this time that supports V because a ratified version of V doesn't exist. SiFive produces Mac binaries for their cores, but the V support is mostly for their own customers doing silicon work with their cores or on a simulator. See https://lists.riscv.org/g/tech-vector-ext/message/364 Since the various drafts of V are incompatible with each other, prepare to be meticulous about matching whatever V support is produced by whatever branch you find with whatever V support is supported by your emulator or whatever pre-release version is supported by your use case. It's probably still too much of a wild west for Homebrew. Someday, 1.0 will be passed and it'll get integrated into GCC upstream. See Jim's comments in https://lists.riscv.org/g/tech-vector-ext/topic/74053961?p=Created,,,20,2,0,0 for one of the many discussions on how messy this situation is. Until then, integration really is left to those working with prerelease drafts. |
|
Thank you @GPSBabelDeveloper for your thorough and very correct comment! Yes, the homebrew only pulls from the riscv-gnu-toolchain repo, and even that sometimes doesn't quite keep up anymore. Perhaps it is time to build from gcc proper such as #36. |
|
You're welcome. Keeping all the parts of the chain in sync has been a problem since I first started messing with GNU chain builds in the late 80's. On some obscure target, GCC does something AS doesn't like. On another, AS does something LD doesn't like. On a third, LD does something GDB doesn't like, etc... (We had this close to home about this time last year when I was the first one that tried this tap on M1 and we got into trouble with host OS issues, while a relevant patch had been upstreamed for a while, but we were too old for that change to work so we just dropped a big hammer on it.) My guess is that people doing RISC-V work on a Mac are probably capable of building their own packages and doing the integration themselves. (Maybe Homebrew helps installing dependencies...) Slotting in development builds of any of them individually would be dangerous, but building the four I mentioned earlier (I don't use their libc, so I can't speak there) from release trees independently from their sources and then overlaying the install either via a different --exec-prefix that's $PATHed first (doesn't always work) or one that's on an fsoverlay (do Macs even have that?) would let the packages seem like merges. Even THAT only helps with #36 and not #75. Here, assuming the person is on real (not simulated) hardware needed a GCC from another vendor completely and it's not all clear that you can just match that willy-nilly with its other siblings. Mixing a Allwinner V0.7.1 GCC would require an allwinner assembly to eat the new opcodes, a new debugger to display the V registors, and a new libc-like substance to provide the macro-op magic needed to represent loops in V. Time has changed the nature of this question, though. The previous remains true. You still need Allwinner's tools to work with D1 and D1s and those are about to become Very Popular devices now that they're $11 boards using a V that GCC, etc. has no interest in supporting. However, V 1.0 was ratified last week (Maybe early this week.) and Vector 1.0 support should now be the NEXT release of all the GNU stuff. I've heard that LLVM is further along in integration (i.e. auto loop vectorization) but I don't know their stance on the old, should-be-unsupported-but-now-we-have-to 0.7.1. To make it extra ugly, getting the 071 chain from T-Head requires signing an NDA and pulling it from China, with all that entails. I haven't seen the source separately, but maybe once someone extracts the source of those RPMS or APKs, distribution for other hosts gets easier. GCC 12 comes in a few momths and should have V. By approximately then, Binutils and GDB should have new releases in the queue or already fired to handle the missing pieces. RISC-V parts are gonig to be powerful enough to run Linux on them natively; anyone developing Linux code can just use that set. Developers of other OSes still ned their own Mac-native ports. For your own sanity, unless you want to start offering completely alternative versions of everything in this package, I'd just wait for the dust to settle and answer "when GNU releases have them we will , too." It's just messy out there. Even with a prod, our OP hasn't said exactly what they want to generate. |
|
See my homebrew-riscv. |
|
Suggest adding WHICH version of Vector is supported since the only chip you
can buy (I think still true) is the pre-ratification D1 family with 0.7.1
but plenty of people are working with simulators or FPGA and such with 1.0.
…On Thu, Dec 23, 2021, 3:11 AM victoryang00 ***@***.***> wrote:
See my homebrew-riscv <https://github.com/victoryang00/homebrew-riscv>.
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD2XETJYISDA2X3PN3DUSLKSVANCNFSM5HCRQ4EA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I installed
Here is my build command:
Any suggestions on? |
|
Gcc vector support has been depriorutized. Use LLVM if you need V,
especially auto vectorization.
…On Mon, Feb 7, 2022, 8:05 PM Hossein Askari ***@***.***> wrote:
I installed riscv-gnu-toolchain using brew reinstall --build-from-source
riscv-gnu-toolchain and I was hoping to be able to compile for a vector
machine. However, It seems the command above does not enable the vector
extension and I am keep getting errors like this:
Error: cannot find default versions of the ISA extension v
Here is my build command:
/opt/homebrew/bin/riscv64-unknown-elf-gcc -mcmodel=medany -march=rv64gcv
-mabi=lp64d -static -std=gnu99 -O3 -ffast-math -fdiagnostics-color=always
-g simple_vector_add.c -o simple_vector_add
Any suggestions?
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD7QQYAIJP7DDQB3E63U2B27HANCNFSM5HCRQ4EA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks for your answer, Is there any homebrew tap that I can use? I tried to compile LLVM with vector extension using instructions provided in Ara: https://github.com/pulp-platform/ara |
|
I'm not familiar and you didn't include errors or context.
I'd never heard of Ara, but V. 10 is positively ancient and it's likely
that nothing contemporary supports that. There's already a big rift between
0.7.1 (shipping in one chip) and the ratified (in December) 1.0 which isn't
on any chip you can buy today.
…On Mon, Feb 7, 2022, 8:32 PM Hossein Askari ***@***.***> wrote:
Thanks for your answer, Is there any homebrew tap that I can use? I tried
to compile LLVM with vector extension using instructions provided in Ara:
https://github.com/pulp-platform/ara
it worked perfectly on a linux machine but on my Mac, it fails when it
tries to compile toolchain-llvm-rt:
https://github.com/pulp-platform/ara/blob/ede4c58bf6a4153b0adba7f3561800383e9b4ca8/Makefile#L95
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VADZVXVTWYIRCJ4KWIPDU2B6DNANCNFSM5HCRQ4EA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks again for your reply. Here is the error log when I try to compile Keep in mind that r Ara is a 64-bit Vector Unit, compatible with the RISC-V Vector Extension Version 0.10. And again, I am able to compile |
|
It looks like someone/something isn't picking up int_least8_t, which should
be defined in <stdint.h> Try including that or find out why it's not being
included. It looks like a common problem
in compiler-rt/lib/builtins/atomic*. so it's probably inside some common
header that's included by the atomics code in that directory. If you can't
work it out, head to https://llvm.org/docs/HowToSubmitABug.html; I don't
know if IRC, Mailing Lists, or heading straight to the bug tracker works
best for this.
But let me reiterate: even if you get it building, the development trunk
is probably not going to actually generate code for V 0.10. I think they
removed code for 0.7.1, which is actually shipping on a somewhat popular
chip in favor of supporting only the ratified V 1.0. It seems extremely
unlikely there's support for 0.10 draft. You may have to look for an old
version of LLVM to support your old version of RVV, if it was ever
supported at all. Most of the development teams have taken the stance of
not supporting any of the draft versions of anything in the long term as
it's a support nightmare. This leads to the super weird situationi right
now that things in the real world (VLC did it this week) are supporting
RISC-V extensions that exist only virtually or in ASIC/emulation instead of
in "real" chips on developer boards.
Successfully building a compiler and having a compiler that emits opcodes
and patterns appropriate for your target are two somewhat related things.
The second depends on the first. With minor changes, you should be able to
get it working on MacOS as well as you do on Linux. What you're showing
probably comes down to a missing #define or an #include or something
finding a native header instead of a cross header or something. It's likely
to be minor when you find it.
Good luck. Your best help is likely to come from within the LLVM community.
…On Mon, Feb 7, 2022 at 9:13 PM Hossein Askari ***@***.***> wrote:
Thanks again for your reply. Here is the error log when I try to compile
llvm-rt:
error_llvm_rt.log
<https://github.com/riscv-software-src/homebrew-riscv/files/8020378/error_llvm_rt.log>
Keep in mind that r Ara is a 64-bit Vector Unit, compatible with the
RISC-V Vector Extension Version 0.10. And again, I am able to compile llvm
and llvm-rt on a linux machine but I get the above error when I try to
compile it on my Mac (I have a Mac with M1 chip).
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VADYHBSRCBHDX2Q44P7TU2CC3ZANCNFSM5HCRQ4EA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
For D1 board, you could just download T-head toolchains with options |
|
D1 (and the rather more rare C910 chip that's also based on the T-head
cores) implements 0.7.1.
Which of those builds is appropriate for MacOS? Because the site seems to
require registration or some kind of password. Even with Google Translate,
I can't coorce enough English out of it to penetrate.
If the Homebrew team is willing to take on the support load of what's
essentially a dead vendor-specific implementation of the chain, it would be
good for someone with need/fluency in such things to help spin up a build
for a tap. Someone probably needs to answer how to get support for a
vendor-proprietary toolchain...in a language understood by the maintainer.
Maybe that volunteer is you.
You don't have to read too much between my words to see that I'm not
volunteering to do so, but I know that D1 is only going to continue to sell
no matter how distasteful I find Allwinner's handling of this part.
T-head/Allwinner should upstream these changes to improve their
visibility/supportability, IMO, but I respect that wasn't the question
asked. :-)
…On Tue, Feb 8, 2022 at 8:28 AM victoryang00 ***@***.***> wrote:
For D1 board, you could just download T-head toolchains
<https://occ.t-head.cn/community/download?id=3913221581316624384> with
options -march=ck806, they have other modifications to the spec other
than VExt.
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VADZTUFV42UNNYGDZDADU2ESB5ANCNFSM5HCRQ4EA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I'm reluctant to come back to this after I've already said this is the
wrong place to ask about something that probably won't meet your
expectations anyway, but since just had to spin through an LLVM build for
unrelated reasons, I just wanted to report back that the LLVM trunk
successfully builds on MacOS (uname -r: 21.3.0) and emits perfectly lovely
RVV 1.0 code.
Using the config recipe from https://github.com/sifive/riscv-llvm, my M1
chomped through all 3300-ish compiles with merely one "variable not used"
warning and crafted an LLVM. When I then use the source from
https://godbolt.org/z/xad7fn8Gz, I get the same vector code that Godbolt
generates from clang13 with the pertinent part being:
my_memcpy:
beqz a2, .LBB1_2
.LBB1_1:
vsetvli a3, a2, e8, m4, ta, mu
vle8.v v8, (a1)
vse8.v v8, (a0)
sub a2, a2, a3
add a1, a1, a3
add a0, a0, a3
bnez a2, .LBB1_1
.LBB1_2:
ret
.Lfunc_end1:
.size my_memcpy, .Lfunc_end1-my_memcpy
.ident "clang version 15.0.0 (
https://github.com/llvm/llvm-project.git
7d7ebf3cf06e6845dc5b83912f0adecbf69e1123)"
So we're way off topic for this report, but Clang trunk DOES successfully
build and generate RVV code for me.
Good luck in finding the difference for your case.
…On Tue, Feb 8, 2022 at 2:59 PM Robert Lipe ***@***.***> wrote:
D1 (and the rather more rare C910 chip that's also based on the T-head
cores) implements 0.7.1.
Which of those builds is appropriate for MacOS? Because the site seems to
require registration or some kind of password. Even with Google Translate,
I can't coorce enough English out of it to penetrate.
If the Homebrew team is willing to take on the support load of what's
essentially a dead vendor-specific implementation of the chain, it would be
good for someone with need/fluency in such things to help spin up a build
for a tap. Someone probably needs to answer how to get support for a
vendor-proprietary toolchain...in a language understood by the maintainer.
Maybe that volunteer is you.
You don't have to read too much between my words to see that I'm not
volunteering to do so, but I know that D1 is only going to continue to sell
no matter how distasteful I find Allwinner's handling of this part.
T-head/Allwinner should upstream these changes to improve their
visibility/supportability, IMO, but I respect that wasn't the question
asked. :-)
On Tue, Feb 8, 2022 at 8:28 AM victoryang00 ***@***.***>
wrote:
> For D1 board, you could just download T-head toolchains
> <https://occ.t-head.cn/community/download?id=3913221581316624384> with
> options -march=ck806, they have other modifications to the spec other
> than VExt.
>
> —
> Reply to this email directly, view it on GitHub
> <#75 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC3VADZTUFV42UNNYGDZDADU2ESB5ANCNFSM5HCRQ4EA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Hello! Sorry to resurrect this... Just wanted to clarify: Is there a homebrew command that will use this tap in conjunction with the LLVM trunk for V-extension support? I apologize if this is a dumb question, I am not at all familiar with homebrew beyond |
No, but I could make a homebrew formula using https://chocopy-llvm.github.io/chocopy-llvm/#/common/build. |
|
If it’s not too much trouble that would be fantastic! :)
…On Thu, May 26, 2022 at 03:10 victoryang00 ***@***.***> wrote:
Hello! Sorry to resurrect this... Just wanted to clarify:
Is there a homebrew command that will use this tap in conjunction with the
LLVM trunk for V-extension support? I apologize if this is a dumb question,
I am not at all familiar with homebrew beyond brew install
No, but I could make a homebrew formula using
https://chocopy-llvm.github.io/chocopy-llvm/#/common/build.
—
Reply to this email directly, view it on GitHub
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHT3VHOXUS75LQPARQOJK23VL4PWPANCNFSM5HCRQ4EA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Does the current version support the vector extension?
I try running this:
riscv64-unknown-elf-gcc main.c asm_func.s -o ./a.out -march=rv64gcv
and getting this:
Assembler messages:
Error: cannot find default versions of the ISA extension
v' /var/folders/qk/896_3mtn7ls3t09tdm0lr2jr0000gn/T//ccIFKgs2.s:3: Error: cannot find default versions of the ISA extensionv'Assembler messages:
Error: cannot find default versions of the ISA extension `v'
The text was updated successfully, but these errors were encountered: