Skip to content
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

Signed division via Arith #54

Merged
merged 1 commit into from
Oct 26, 2023
Merged

Signed division via Arith #54

merged 1 commit into from
Oct 26, 2023

Conversation

MCJOHN974
Copy link

Signed division via arith for i32 and i64

@MCJOHN974 MCJOHN974 requested a review from nagisa October 25, 2023 12:19
@MCJOHN974
Copy link
Author

Due to discussion in zulip I think we can don't care about overflows in this PR and make another PR which cares about all overflows work properly after most part of arithmetic will be implemented (and maybe zk processor switches to 64 bit?)

collector.reg_clobbers(clobbered);
// Division via ARITH perform different operations with registers A, B, C, D,
// so they can not be result register for proper division
collector.reg_fixed_def(rd, e0());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, I was under impression that in order to check DIV with ARITH, we’d have to use E, D and B registers as inputs, and A would be the output or something like that? I’m quite lost how this is supposed to work at this point…

Copy link
Author

@MCJOHN974 MCJOHN974 Oct 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yes, with convention that div performs A := E / B we have 2 lines of bytecode less. But we still have to fix all the registers, because if we will allow register allocator freely choose output register, B for example can be chosen, and it will broke the ARITH assertation. Done here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

D and C also should be set to zero when we perform ARITH assertation

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think A := E / B is optimal for DivArith in assumption less lines of zkAsm code => better performance

; ((_ InstOutput (gen_div_overflow x y $I64))
; (_ InstOutput (gen_div_by_zero y)) )
; (rv_div x y)))
(rule -1 (lower (has_type (fits_in_32 ty) (sdiv x y)))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can drop this rule entirely I believe, and have something like

(rule (lower (sdiv x y))
     (zk_div x y))

Copy link
Author

@MCJOHN974 MCJOHN974 Oct 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it works, added here. But maybe splitting to two lowering patterns will help in future when we will adding smaller types?

Copy link
Collaborator

@nagisa nagisa Oct 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think it is worth thinking about it right now – ISLE is reasonably easy to extend when needed, but quite hard to simplify later in my experience, so its better to do the simple thing first. In fact I hope that we can remove most of the isle code and replace it with the few simple rules like these initially.

@MCJOHN974 MCJOHN974 added this pull request to the merge queue Oct 26, 2023
Merged via the queue into main with commit 8a26b2e Oct 26, 2023
21 checks passed
@MCJOHN974 MCJOHN974 deleted the viktar/div branch October 26, 2023 12:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants