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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
