-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
stage2: vectorized overflow arithmetic, integer overflow safety, left-shift overflow safety #11316
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
Conversation
6d8d0cb
to
dd6a581
Compare
dd6a581
to
fc47c9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add a few more test cases
if (builtin.zig_backend == .stage2_x86_64) return error.SkipZigTest; // TODO | ||
if (builtin.zig_backend == .stage2_aarch64) return error.SkipZigTest; // TODO | ||
if (builtin.zig_backend == .stage2_arm) return error.SkipZigTest; // TODO | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing tests: u8 underflow, i8 overflow and underflow.
edge cases: u1, u0
cc @kubkon @joachimschmidt557 - could we prioritize getting the overflow arithmetic AIR instructions working in the backends so that we can move forward with this without regressing too many x86 and ARM test cases? Perhaps even an initial, inefficient implementation that stores the result tuple into a stack allocation, and then a follow-up enhancement that tries to avoid this? |
SGTM! Will do just that for x64 tomorrow! |
I'm currently working on implementing the relevant instructions for ARM. My progress in on the branch I usually use (https://github.com/joachimschmidt557/zig/tree/stage2-arm). I can't promise anything, but I'll probably be done with all instructions for all integers <= 32 bits in a couple of days. |
related issue #6017 |
4cd7cbe
to
3f8f3c5
Compare
Rebased! I fixed LLVM's vector codegen, but the CBE and the Arms are missing a couple things still. |
3f8f3c5
to
d7cfc23
Compare
@wsengir rebased on top of master - only CBE should be missing now! 🎉 |
I'll take a look at the CBE today. |
Looks like the behavior tests are failing for the native wasm backend in this branch too. I'm working on the C backend right now. |
Trying my best to have them pass by tomorrow. Jakub brought the incorrect shifting behavior to my attention already, but haven’t had the time to fix it yet. |
✔️ C backend |
@kubkon mind having a look?
|
@andrewrk on it! |
@andrewrk x64-macos fixed. We still get an implicit decl error with CBE though:
|
Ah yes I'll take care of that tomorrow. I'll need to add some new compiler-rt routines for these functions. Unless... someone else happens to do it before I wake up 🙈 |
It's now passing for the native Wasm backend also. |
ad8ab4e
to
70dbe2f
Compare
@joachimschmidt557 FYI that I had to disable recursive fibonacci test for now. |
@andrewrk should be good to go! |
Looks like the next problem is more C backend stuff |
Most of the work here was additions to zig.h. The lowering code is mainly responsible for calling the correct function name depending on the operand type. Some of the compiler-rt calls here are not implemented yet and are non-standard symbols due to the C programming language not needing them. After this commit, the behavior tests with -ofmt=c are passing again.
The implementation for add_with_overflow and sub_with_overflow is now a lot more robust and takes account for signed integers and arbitrary integer bitsizes. The final output is equal to that of the LLVM backend.
This re-implements the shl_with_overflow operation from scratch, making it a lot more robust and outputs the equal code to the LLVM backend.
* zig_addo_u128: fix type-o * redo the shift-left overflow inline functions. no need to depend on compiler-rt.
This avoids the following error: ``` error: incompatible pointer types passing 'int64_t *' (aka 'long long *') to parameter of type 'long *' overflow = __builtin_saddl_overflow(lhs, rhs, res); ^~~ ``` My previous understanding was that this error would not occur because prior to this line we check that int64_t is equivalent to long, like this: ```c ``` However, it appears that this is still a warning in C if int64_t is primarily aliased to `long long`, even though `long` and `long long` are the same thing.
b526572
to
f33b3fc
Compare
Sorry for yet another probably too big PR, but the changes were dependent on each other, and I didn't want to wait for the first to get merged before PRing the rest.
This breaks basically everything that's not LLVM.