[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)
Nikita Popov via cfe-commits
cfe-commits at lists.llvm.org
Fri Mar 8 03:11:21 PST 2024
nikic wrote:
So yeah, I think the source-relative representation is better if we consider only the current vtable / GlobalSplit use case (where we'd just convert result-relative to source-relative anyway), while the result-relative representation is better if we consider a potential extension to instruction GEP / non-constant indices in the future.
If we have something like
```
struct Foo { int a, int b, int c };
struct Foo foo[100];
fn(&foo[x]);
```
then we could pass `ptradd ptr inrange(0, 12) @foo, i64 %x * 12` to the function and know (for AA purposes) that it only accesses a single struct in the array.
This would also be consistent with the alternative intrinsic based representation, which would go something like `%p = ptradd ptr @foo, i64 %x * 12; %p2 = call @llvm.memory.region.decl.p0(ptr %p, i64 0, i64 12)`.
-----
With that in mind, I'm leaning towards keeping the result-relative encoding. For constant GEPs it makes little difference because we can also ways just add/subtract the necessary offset, but this seems more future-proof if we do decide to extend to instructions.
https://github.com/llvm/llvm-project/pull/84341
More information about the cfe-commits
mailing list