ConstraintAnalysis: Increment constants - #8969
Conversation
|
|
||
| // Apply an increment of a local, x = y + 1. | ||
| Index y; | ||
| if (matches(value, binary(Abstract::Add, local(&y), ival(1)))) { |
| approximateAnd(index, c); | ||
| } | ||
|
|
||
| void BasicBlockConstraintMap::set(Index index, |
There was a problem hiding this comment.
We can redefine the existing set in terms of this one.
There was a problem hiding this comment.
It might be less efficient, though. We can apply a single constraint without a loop, and without checking if the set is empty.
There was a problem hiding this comment.
Though I guess inlining might make it fast. I'll simplify and then see if it shows up in profiles later.
| Index y; | ||
| if (matches(value, binary(Abstract::Add, local(&y), ival(1)))) { | ||
| // The local y must have old constraints that we know how to increment. | ||
| auto old = get(y); |
There was a problem hiding this comment.
Do we need to be making a copy here?
There was a problem hiding this comment.
Yes, see how we modify the copy in-place, below.
| case Eq: | ||
| *N = N->add(Literal::makeFromInt32(1, N->type)); | ||
| continue; | ||
| // x >= N, x++ => x > N |
There was a problem hiding this comment.
We could simplify this by always just updating the constant (by adding one, although it looks like this would be pretty easy to generalize) and leaving the operator alone.
There was a problem hiding this comment.
Hmm, true. However, that would require checking for overflows in more places, and also make things more complicated later when we have non-constants (when x < y, x++, we can infer x <= y without incrementing anything, and in fact can't increment).
| // when it reaches the loop bound, which may be very high. We don't want to | ||
| // spend significant time on such constant operations, as other passes will | ||
| // propagate them anyhow, so we verify that we don't apply such x = y + 1 | ||
| // operations too many times. |
There was a problem hiding this comment.
I was expecting to see a new "widening" mechanism to prevent unbounded iteration, but I don't see it. Am I missing something?
There was a problem hiding this comment.
You are seeing the future, for that is in the next PR 😄
2 participants
If we know
x == Cand havex++, we can set it tox == C + 1, etc.A risk when computing this is that we might end up doing
x++from0 to 1 to 2 to 3 and so forth, until we reach some high limit. Add a
mechanism to stop such incrementing after a linear amount of work.
This is necessary to compute loop overflows.