evalengine: Internal cleanup and consistency fixes #14854
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While working on vitessio#14841 and running some tests, I ran into some other issues / consistency problems in the evalengine that we can clean up and fix. First we use `time.Duration` for intervals, which already provides constants and we don't have to deal with nanoseconds then separately but they are part of durations. We clean up the tinyweight function which does a bunch of casting which works but isn't as clear and would actually break on 32 bit (but we don't support that anyway). It now also returns 0, 1 or -1 which is more how other Go `Cmp` functions work. We remove `int` from `dataOutOfRangeError` since the `evalengine` only works with `int64` or `uint64` anyway, so any usage of `int` would really be a bug (and we didn't deal with `uint` either so it was inconsistent anyway). The bit shift operations also need to operate on int64 explicitly, since that's what the inputs are in the `evalengine`. So we should keep the types consistent. Next, we were missing a now possible optimization which is that we have size for temporal times at compile time. This means we know if we need to convert to integer or decimal. We don't hit the deoptimize path anymore, and now also error hard if that happens since compilation is broken in that case. Lastly we were not dealing with underflow / overflow checks correctly in `FROM_UNIXTIME` between the evaluator and compiler. We need to check before conversions, because specifically float64 to int64 conversions have badly defined behavior for large float64 values. It behaves differently on amd64 vs arm64 vs i386 for example already. Some convert large values to negative ints, others positive or even other values. By checking before casting we avoid this and can behave consistently. Signed-off-by: Dirkjan Bussink <[email protected]>
dbussink
requested review from
harshit-gangal,
systay,
frouioui,
GuptaManan100,
shlomi-noach,
vmg and
mattlord
as code owners
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
vitess-bot
bot
added
NeedsBackportReason
dbussink
commented
Dec 22, 2023
| @@ -559,52 +559,81 @@ func (b *builtinFromUnixtime) eval(env *ExpressionEnv) (eval, error) { | |||
|
|
|||
| switch ts := ts.(type) { | |||
| case *evalInt64: | |||
| if ts.i < 0 || ts.i >= maxUnixtime { | |||
| return nil, nil | |||
| } | |||
There was a problem hiding this comment.
It's repetitive, but we have to check up front here. Some fun things:
amd64
Large float turns into negative int64.
int64(1.2345678912345678e300)
-9223372036854775808
arm64
Large float64 turns into max int64.
int64(1.2345678912345678e+300)
9223372036854775807
This means we can't convert before checking overflow / underflow since it won't be consistent.
| length = len(num) | ||
| bits = int64(shift % 8) | ||
| bytes = int64(shift / 8) | ||
| length = int64(len(num)) |
There was a problem hiding this comment.
bit shifting operates on int64 so we should use that consistently.
dbussink
added
Type: Internal Cleanup
Component: Evalengine
Signed-off-by: Dirkjan Bussink <[email protected]>
Signed-off-by: Dirkjan Bussink <[email protected]>
dbussink
commented
Dec 22, 2023
| return (dt.Date.Day()-1)*secondsPerDay + dt.Time.toSeconds() | ||
| func (dt DateTime) toDuration() time.Duration { | ||
| dur := dt.Time.toDuration() | ||
| if !dt.Date.IsZero() { |
There was a problem hiding this comment.
When we have a zero date (and thus we're a Time type), we don't include the day bit to have a correct duration.
| dur := dt.toDuration() | ||
| dur += itv.toDuration() | ||
| days := time.Duration(0) | ||
| if !dt.Date.IsZero() { |
There was a problem hiding this comment.
Rounding shouldn't move days if we're a Time instance. We then can have more than 24 hours.
Signed-off-by: Dirkjan Bussink <[email protected]>
mattlord
approved these changes
Dec 26, 2023
Signed-off-by: Dirkjan Bussink <[email protected]>
GuptaManan100
approved these changes
Dec 27, 2023
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While working on #14841 and running some tests, I ran into some other issues / consistency problems in the evalengine that we can clean up and fix.
First we use
time.Durationfor intervals, which already provides constants and we don't have to deal with nanoseconds then separately but they are part of durations.We clean up the tinyweight function which does a bunch of casting which works but isn't as clear and would actually break on 32 bit (but we don't support that anyway). It now also returns 0, 1 or -1 which is more how other Go
Cmpfunctions work.We remove
intfromdataOutOfRangeErrorsince theevalengineonly works withint64oruint64anyway, so any usage ofintwould really be a bug (and we didn't deal withuinteither so it was inconsistent anyway).The bit shift operations also need to operate on int64 explicitly, since that's what the inputs are in the
evalengine. So we should keep the types consistent.Next, we were missing a now possible optimization which is that we have size for temporal times at compile time. This means we know if we need to convert to integer or decimal. We don't hit the deoptimize path anymore, and now also error hard if that happens since compilation is broken in that case.
Lastly we were not dealing with underflow / overflow checks correctly in
FROM_UNIXTIMEbetween the evaluator and compiler. We need to check before conversions, because specifically float64 to int64 conversions have badly defined behavior for large float64 values. It behaves differently on amd64 vs arm64 vs i386 for example already. Some convert large values to negative ints, others positive or even other values. By checking before casting we avoid this and can behave consistently.Related Issue(s)
Found when working on #14841
Checklist