Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: prove pass disabled on int32/int64 #29964
Consider this program:
The bounds check for x[j-1] can be eliminated: at that point, x[j] did not panic, so j < len(x), and the if statement has also tested j > 0, so 0 <= j-1 < len(x).
The compiler does eliminate this check:
But if I change j to be int32 then the check is not eliminated:
Is this necessary? /cc @aclements
I think this is probably because we extend indexes to int width before we do the bounds check.
The code in ssa.go for OINDEX does:
The extra cast probably makes the prove pass give up, because it can't go from
We could do the bounds check before the extension. That would fix this problem, probably. I'm not sure what else it would do. Probably it would be fine, it was just easier when first implementing ssa to only deal with one index type during bounds check generation.
We do need
@randall77, I am not sure I follow completely, but
It should be able to go in two steps, from
Is the problem that the prove pass does not explore a "two-step" option
When testing the negative branch of the offending bounds check, prove asserts that
In the int32 case, the inequality being asserted on the negative branch of the bounds check is instead
Relevant SSA blocks for
I've found what seems to me like an unobtrusive change that fixes this issue, though it is pretty specific to this case. I'm not sure how complicated a more general solution would be, I have to think about it more.
When the bounds check assertion is first produced by addBranchRestrictions(), the value.Op can be checked for an extension, and the underlying value passed-through. After a quick test, this change seems to also rely on the pending CL 122695 referenced above. I have to play with it a bit more to find out exactly why that is.
Oops, I'd failed previously to account for the sign extension at the first bounds check, where prove needs to learn that
CL is forthcoming.
@zdjones That's a possibility. I don't think it is easy, though. If we did that we'd need to compare, say, a 16-bit index with a 64-bit length. Those instructions don't exist on most (any?) processors.
For 32-bit archs,