-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
arch-riscv: remove branching from vset{i}vl{i}
instruction and allow registers vl
and vtype
to be renamed
#885
Comments
I'm going to push back on this solution because the spec says that Correct me if I'm not interpreting the spec correctly :) |
Yes, the spec says Having I understand that gem5 should be as close to spec as possible, so if this is not something we want to have upstream we will keep it internal. |
It's an intriguing option. I also think looking into speculating on I think I know the answer to this question, but I'll ask anyway. Do you think it's feasible to make it a configuration-time parameter whether The other direction we can discuss is how to make the ISA spec implementation of these instructions flexible enough to enable both "in core" vector operations (i.e., the vector ops are renamed/executed/etc in the same pipeline as all other instructions) and a vector co-processor design. In this case, we could have different implementations that hit different points in the design space. I think this needs to be a longer conversation. To have the conversation we could go two ways:
In other words, I would like to discuss the overall goals/requirements for this model, the possible implementations, and the tradeoffs of these implementations. We could do this either synchronously on zoom or asynchronously with a lot more writing. |
Sorry it took a while to get back to you on this one. I wanted to understand the amount of changes we had to do to see if the parametric solution is feasible. As we both were anticipating, changes in the isa definition side are necessary and making these parametric would not be easy. But will take a look after we have tested the prototype implementation we have. The second topic is an interesting one. We are currently focused on scaling our simulations and adding other features (that are being upstreamed), but midterm I think this discussion will be of interest. I will try to get onto a developers meeting (if schedule permits), and we can kick start this discussion and move on to focused zoom sessions if necessary. |
Hi @aarmejach, we have a developer meeting scheduled for next week on April 11th at 4pm UTC. Would you be available to join? If so, how would you prefer to discuss this topic? Are you interested in preparing a presentation with a couple of slides? Thanks. |
hi @ivanaamit, sure, I'll join the meeting. I have not thought much on the "in core" vs. "co-processor" execution model in gem5 to be honest, as it is not something we are considering at the moment. Regarding this issue, we have implemented a solution in which We went this path as it required little changes and goes around the issue that |
Currently the
vset{i}vl{i}
family of instructions is branch-like. This works well for some applications, but for others, especially those where thevset{i}vl{i}
instruction is inside a loop which changes thevl
/vtype
state on every iteration, do not perform well due to constant squashing.The proposal aims to eliminate the branch-like behavior of the
vset{i}vl{i}
instructions and, instead, set thevl
andvtype
registers as renameable, allowing for normal data dependencies to be created with subsequent vector instructions in the execution flow.@adriaarmejach and I discussed two approaches:
The later approach seems cleaner (new register class addition would be similar to the changes in commit fed81f3) but it involves more overall code compared with the first one.
Open to discussion.
The text was updated successfully, but these errors were encountered: