[llvm] [DA] Widening SCEV expressions in strong SIV test to prevent overflow (PR #164704)
Ehsan Amiri via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 23 10:20:15 PDT 2025
amehsan wrote:
> As you said we may be able to prove in some way that `2*n` doesn't overflow, it looks to me that such reasoning will require non-trivial effort. In addition, I believe that the cases where such inference can be applied are quite limited. For example, it the store is not `A[i + 2*n]` but `A[i + 7*n]`, then I don't think we prove `7*n` doesn't overflow. Actually, when `n` is `7905747460161236407`, which is a modular multiplicative inverse of 7 with respect to the modulus `2^64`, the program will be well-defined while `7*n` overflows.
That example is a separate issue. That is not related to this patch. and that case is not something that we want care about its accuracy.
> If simply widening the integer type improves accuracy in many cases compared to bailing out when an overflow occurs, that would be great. However, looking at the tasks listed in https://github.com/llvm/llvm-project/issues/159846#issuecomment-3416695148, I don't think that's the case.
The issue is not how many hanadwritten testcases can be improved. The issue is how often this can help in the real and unseen code. In an arithmetic operation where one of the involved expressions is symbolic, it is very difficult to prove the result won't overflow. Simply because often times we don't have any bound on the value of the symbolic expression. This is why I proposed widening in the first place. For symbolic intermediate computations in DA, without widening we have to give up on many real-world cases very quickly. @1997alireza can post an example to clarify this.
The complexity increase is very small here. Once we miss a performance opportunity it is not easy to detect it. Once detected, it takes a lot of effort to find the root cause, come up with the idea and implement it. So if you consider longer term, I expect significant benefit from this patch.
https://github.com/llvm/llvm-project/pull/164704
More information about the llvm-commits
mailing list