KVM: riscv: Unify and optimize FP register loops
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest2 patches 0 repliesNew
- v12 patches 0 repliesSuperseded
Changes in v2 from the cover letter
- Both patches had the same flawed line of code. The checking if the token's size was 32 or 64 bits line allowed token's with mismatched sizes & types to pass. I fixed this by checking it had the right size for its type by replacing the u32/u64 parts with a mode-dependent local variable, byte_offset.
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | KVM: riscv: Eliminate redundancy in get_reg function via pointersarch/ | +39 | 0 replies | |
| 2/2 | KVM: riscv: Eliminate redundancy in set_reg function via pointersarch/ | +36 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH v2 0/2] KVM: riscv: Unify and optimize FP register loops
The change to both patches in this series is a structural/architectural one. Both functions set_reg and get_reg use identical code to locate the register the application specified in the token even though they do different things with that location
information: the set_reg function adds data the application requested to send to that identified location (in the copy_from_user function) while the get_reg function retrieves what data is at that identified location and sends it to the application (using the copy_to_user function). Everything else is the same. That is the only difference between the code.
Therefore I was able to apply the same solution to both of the function's finding-the-requested-register parts (which is everything up until the final if statement) which were filled with redundancy. The solution I came up with is to create local variables for the entire function for all the variables of the original code that would be different, depending on the floating point type. Then once I ask whether it is a double floating point or single floating point mode, I assign the aforementioned variables to the values they should have for that mode so that when I go through the if statements that ask whether the requested register number is a status control register or data register, I only have to go through it once because the respective floating point values/addresses would have been assigned to the aforementioned local variables, so the whole code kind of changes or is tailored to the floating point type.
This architectural change/solution will make the cpu execute the code faster (as the cpu will have less decisions to make and the bare-metal math used to figure out the address of the register is executed faster by the cpu than looking up object properties and array indexes), is more maintainable, and is more readable.
---
v2:
- Both patches had the same flawed line of code. The checking if the token's size was 32 or 64 bits line allowed token's with mismatched sizes & types to pass. I fixed this by checking it had the right size for its type by replacing the u32/u64 parts with a mode-dependent local variable, byte_offset.
Paul White (2):
KVM: riscv: Eliminate redundancy in get_reg function via pointers
KVM: riscv: Eliminate redundancy in set_reg function via pointers
arch/riscv/kvm/vcpu_fp.c | 124 +++++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 52 deletions(-)
Signature · 1 line
2.53.0