-
Notifications
You must be signed in to change notification settings - Fork 147
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
Speed up, harmonize BitReduction #2244
Conversation
32649b1
to
d06e778
Compare
Ooops, silly me. Hold on. |
d06e778
to
cbb65c9
Compare
Okay, now without dumb gaffes. |
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.
Speed ups and harmonization LGTM.
With regards to the XException
change: I think what you're doing here is correct. We've had reports before where people expected an undefined bitvector to have mask ~ maxBound
instead of being a bottom. To me this makes sense, as the latter will break unjustifiably whenever an operation is applied to them. My opinion on it isn't very strong though.
The cases for `reduceAnd` and `reduceOr` where the mask is non-zero can also be sped up just like the cases with a zero mask. `reduceAnd` and `reduceOr` always produce a `Bit`, but possibly with a non-zero mask (i.e., an undefined value). `reduceXor` should also produce such a value, which is different from throwing an `XException` as it did.
cbb65c9
to
383837b
Compare
The cases for `reduceAnd` and `reduceOr` where the mask is non-zero can also be sped up just like the cases with a zero mask. `reduceAnd` and `reduceOr` always produce a `Bit`, but possibly with a non-zero mask (i.e., an undefined value). `reduceXor` should also produce such a value, which is different from throwing an `XException` as it did. (cherry picked from commit 99824af)
The cases for `reduceAnd` and `reduceOr` where the mask is non-zero can also be sped up just like the cases with a zero mask. `reduceAnd` and `reduceOr` always produce a `Bit`, but possibly with a non-zero mask (i.e., an undefined value). `reduceXor` should also produce such a value, which is different from throwing an `XException` as it did. (cherry picked from commit 99824af) Co-authored-by: Peter Lebbing <peter@digitalbrains.com>
The cases for `reduceAnd` and `reduceOr` where the mask is non-zero can also be sped up just like the cases with a zero mask. `reduceAnd` and `reduceOr` always produce a `Bit`, but possibly with a non-zero mask (i.e., an undefined value). `reduceXor` should also produce such a value, which is different from throwing an `XException` as it did.
The cases for `reduceAnd` and `reduceOr` where the mask is non-zero can also be sped up just like the cases with a zero mask. `reduceAnd` and `reduceOr` always produce a `Bit`, but possibly with a non-zero mask (i.e., an undefined value). `reduceXor` should also produce such a value, which is different from throwing an `XException` as it did.
The cases for
reduceAnd
andreduceOr
where the mask is non-zero canalso be sped up just like the cases with a zero mask.
reduceAnd
andreduceOr
always produce aBit
, but possibly with anon-zero mask (i.e., an undefined value).
reduceXor
should alsoproduce such a value, which is different from throwing an
XException
as it did.
Still TODO: