nikic wrote: > Have you thought about the implications for dynamic (non-constant) indices?
inrange is only supported on constant expressions, and I think the consensus is that it should not be extended to non-constant cases. In that case, we would represent the information independently of the GEP using an intrinsic instead. (Technically a constant expression GEP can also have a dynamic index, but that case is not practically relevant.) > Stuff like > > ``` > %gep = getelementptr [50 x {i32, [10 x i32]}], ptr %base, i32 0, i32 > %outer_idx, i32 1, i32 %inner_idx > ``` > > The current representation allows an `inrange` on the second-to-last index > which to my understanding restricts the range to the `[10 x i32]` into which > `%gep` falls structurally. > > It seems like neither proposed representation is able to capture that in a > single `ptradd` (it could be captured with a sequence of two `ptradd`s, but > that's an awkward tradeoff). > > The first proposed representation at least allows handling the case when > there is only a single dynamic index, and the `inrange` is to the right of it. ptradd wouldn't support multi-index GEPs anyway, so the representation would be something like ``` %p1 = ptradd ptr %base, i32 %outer_idx * 44 %p2 = ptradd ptr %p1, i32 4 %p3 = ptradd ptr %p2, i32 %inner_idx * 4 ``` if we support scaling inside ptradd (or separate multiply/shift instructions otherwise). Where `%p1` likely gets LICMed and/or CSEd. If we did support inrange on non-constant ptradd then we would encode the constraints that it's inrange of the inner array as ``` ; relative to source %p2 = ptradd ptr inrange(4, 44) %p1, i32 4 ; relative to result %p2 = ptradd ptr inrange(0, 40) %p1, i32 4 ``` Though if we consider a variant where we don't have that extra constant ptradd (i.e. drop the struct with the `i32` element): ``` %p1 = ptradd ptr %base, i32 %outer_idx * 44 %p2 = ptradd ptr %p1, i32 %inner_idx * 4 ``` And then want to restrict inrange to the inner array, then for the source-relative case we can write: ``` %p1 = ptradd ptr %base, i32 %outer_idx * 44 %p2 = ptradd ptr inrange(0, 40) %p1, i32 %inner_idx * 4 ``` While the result-relative case can't represent this without a dummy ptradd 0. > (I guess this is an extension to @aeubanks' point. It feels like `inrange` > _should_ be useful for things like alias analysis. But I guess it's not used > for that at the moment.) If we supported inrange on instruction GEP, then yes, it would be useful for AA. https://github.com/llvm/llvm-project/pull/84341 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits