-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Bounds Checks] Make union/intersect operations more precise #113862
Conversation
6f4b5c0
to
9545f62
Compare
return l1; | ||
// Otherwise, prefer the BinOpArray(preferredBound) over the constant for the upper bound | ||
// and the constant for the lower bound. | ||
return isLower ? l2 : l1; |
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.
In this case we just tighten the range (from multiple facts), it's fine to be liberal here. Seems like for lower bound it's always better to report a constant than trying to be smart with adjusted "bnd + offset"
@@ -510,10 +510,15 @@ struct RangeOps | |||
{ | |||
result.lLimit = r1lo; | |||
} | |||
// Widen Upper Limit => Max(k, (a.len + n)) yields (a.len + n), | |||
// This is correct if k >= 0 and n >= k, since a.len always >= 0 |
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.
since a.len always >= 0
NOTE: we've been already relying on this fact in RangeOps::Merge before my change
PTAL @jakobbotsch @dotnet/jit-contrib |
if (r1lo.IsBinOpArray() && r2lo.IsConstant() && (r1lo.cns <= 0)) | ||
{ | ||
result.lLimit = Limit(Limit::keConstant, min(r1lo.cns, r2lo.cns)); | ||
} | ||
if (r2lo.IsBinOpArray() && r1lo.IsConstant() && (r2lo.cns <= 0)) | ||
{ | ||
result.lLimit = Limit(Limit::keConstant, min(r2lo.cns, r1lo.cns)); | ||
} |
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.
This is adding more reliance on the unsound limits created based on IsVNCheckedBound
, isn't it?
It's a little bit worrying...
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.
Yep, but we either shouldn't do it at all (depends on the bound actually, if it's VNF_ArrLen then it's always fine to rely on) or keep using it. I hope the "is montonic"/overflow analysis make it safe
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.
LGTM with a small worry around using facts created based on IsVNCheckedBound
/ba-g "azurelinux.3 issues" |
Closes #113809
Partially addresses #104890 (removes bounds check)
We are now able to drop bounds checks completely here: