Open fpedd opened 3 years ago
To 1. I think this is actually interesting, seems we are now "stressing" the ETISS decoder implementation so some bugs surface. Definitely we need to have alook into this but that would rather be something for @rafzi @wysiwyng .
Defintely a good idea.
Yes, we defintely should target the latest Vector release and not spend time on older V versions. Was there not a 1.X Version already?
I woulkd postpone it as we only use V for ML workloads atm.
I think you should report this to @wysiwyng , finally we should run the fully generated files.
Yes, there already is a v1.0-rc1 (released June this year). While it still is a release candidate, the following (taken from the PDF spec) seems pretty ensuring:
When finally approved and the release candidate tag is removed, version 1.0 is intended to be sent out for public review as part of the
RISC-V International ratification process. Version 1.0 is also considered stable enough to begin developing toolchains, functional
simulators, and initial implementations, including in upstream software projects, and is not expected to have major functionality
changes except if serious issues are discovered during ratification. Once ratified, the spec will be given version 2.0.
So it probably was a good idea to not invest too much time into implementing other prior 0.x
versions of the vector standard. But now could be a good time to go forward with adopting the (hopefully mostly stable) v1.0
.
Yes, of course. Only focussing on vector instructions directly beneficial to the ml flow and the muriscv_nn library is most likely the only reasonable approach.
I already talked to @wysiwyng. He is working on this.
While the RISC-V vector extension has already defined a version 1.0, there appears to be no tool support for it as of now. Thus, @rafzi rightfully suggested postponing any further work on implementing the version 1.0 vector extension until one can actually assemble and test version 1.0 vector instructions. This PR is not directly affected by this. But it directly relates to my remarks made in the original comment for this PR.
We are also waiting for this PR to close this issue in order for the Windows build to hopefully succeed here.
This is a work in progress replacement for #71...
Some points that need to be considered:
16460-16640
inArchImpl/RISCV/RISCVArch.cpp
) cause some sort of conflict in the ETISS instruction decoder which results in uninitialized nodes in the instruction set tree, similar to here #74. This results, in contrast to the uninitialized nodes in referenced issue, in segmentation faults when running ETISS. Thus, these instructions are commented out for now.v0.9
(and above?).v0.7
. It might be beneficial to migrate tov0.9+
, especially when considering that the tests usev0.9
and thatmuriscv_nn
should be up-to-date while being able to run on ETISS.EDIT 1: Regarding 1. The RISCVArch.cpp (beware, the file is a pain to work with as it has close to a million lines) in the
v-ext-support
branch doesn't seem to include the VLE.U and VSU.U instructions either. So this could be the reason why the issue is only now emerging. Theml_on_mcu
flow is currently based on ETISS withv-ext-support
when requesting vector support (the muriscv_nn library inst using any vector load/stores as of now).