-
Notifications
You must be signed in to change notification settings - Fork 161
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
Deduplicate some floating point code #448
Conversation
This is the first step of making the float code generic over the float size. There are no functional changes, it just removes code duplication.
Using this alias makes things a bit clearer.
This replaces the separate functions to read/write the floating point registers as smaller widths (which boxes/unboxes them) with single generic functions. Note in some cases we still need to explicitly pass the width in so it might seem like there is no benefit, but those will be removed once the code is fully generic.
Make `fsplit`/`fmake`, `f_is_...` and `f_negate` generic over the float size. The vector code actually already used functions like this. This reduces a lot of copy/pasted code and will allow even more of the code to be deduplicated later.
I'm not sure of the exact history here but only the le function is actually used. I left the other two in for reference. I also changed the flags from functions to global constants, since that's what they are.
Similar to the `F_box` accessor, these can be generic. They just need a special case for xlen == 32 when reading/writing 64-bit floats which are split over two registers when using Zfinx.
@Incarnation-p-lee you might be interested in some of this code, especially these functions - took me a little while to get the types figured out!
But with those you can do generic functions like
and it all type checks nicely. |
Test Results712 tests ±0 0 ✅ - 712 0s ⏱️ ±0s For more details on these failures, see this check. Results for commit cf7553b. ± Comparison against base commit a2ffa85. |
Thanks @Timmmm . That is very cool, I suppose this is what I need shortly. Just complete the API design draft doc, and will work out a POC on the sail side. I bet that will be very helpful. |
I think this probably failed to using an old version of Sail. I will make a PR to update it. |
Oh actually it turns out type level if-then-else was only added to Sail three weeks ago! Very timely. But it means we'll need to wait for the next Sail release for this to compile. |
Got it, I suppose I can leverage SAIL_DIR to the new built one from the sail repo. Let me have a try later(in the middle of fixing ICE for GCC ...) and keep you posted. |
Not sure if below parts can transform to
That would be more friendly for reading, specially when we add fp128 support. |
Unfortunately not work for matches in bits now.
=>
|
Hello, switching on width alone may not be adequate for future-proofing. For example, there is already BF16 format along with "standard" FP16, for 16-bit width floats (see Zfbf). AI/ML will also be adding a variety of 8-, and possibly even 6- or 4-bit floats. (These may only be supported in the vector or matrix instruction sets, and may not even be IEEE754 compliant.) The formats we will support, which differ in the allocation of exponent vs. significand bits, has not yet been nailed down. The point is, if you're changing this code, it may as well be done in a more generic fashion that will work with these future formats. |
Hmm that is a good point. Unfortunately I don't think Sail supports type level enums so supporting multiple 16-bit float formats in this way is going to be a bit tricky. Perhaps the best solution is to make all the functions generic over the split sizes, instead of the total size. Like instead of
have
Quite a bit more tedious to use though. Perhaps we should cross that bridge when we come to it. At the very worst those weird formats can copy & paste the implementations as they would have to now. |
Whatever you feel is best. I just wanted to make sure you were aware of the situation, so that any change you make now won't make it really hard to change later on when these new formats come into use. You still need to figure out how to deal with FP16 vs BF16, and that could provide a template for all the other formats to be added. Rather than the width, maybe you could key off of opcode bits? Hardware decode logic has to do it this way. |
Closing this since we can use the code included in Sail instead. |
This is an initial effort to deduplicate the floating point code (see #432). Currently all the floating point code is copy/pasted for every size of float (f16, f32, f64). That's very verbose and error prone and is going to get worse if people want f128!
It's also unnecessary because Sail has an amazing type system so it can easily deal with functions that are generic over the size of the float.
Note, this PR is composed of 6 commits which all build and work, so I would recommend a rebase merge rather than a squash merge to preserve the history.
Normally I would make the PRs in series, but 6 PRs is going to take like a year to get through our review system so I'm doing it all in one! I recommend reviewing the individual commits though.
Also note some of the changes look like they are kind of pointless, e.g.
F_or_X_H(rs1)
toF_or_X(16, rs1)
, but that's just because this is only part of the solution.