[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-13 Thread Nikita Popov via cfe-commits
https://github.com/nikic edited 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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-08 Thread Nikita Popov via cfe-commits
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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-08 Thread Nikita Popov via cfe-commits
nikic wrote: > 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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-08 Thread Nikita Popov via cfe-commits
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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-07 Thread Nicolai Hähnle via cfe-commits
nhaehnle wrote: Have you thought about the implications for dynamic (non-constant) indices? 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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-07 Thread Arthur Eubanks via cfe-commits
aeubanks wrote: the only use of this is GlobalSplit, and it cares about ranges relative to the GlobalVariable, so if we're not planning on using this in more cases then I'd say relative to the source pointer makes sense. not sure if inrange would ever be useful for more than GlobalSplit, like

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-07 Thread Nikita Popov via cfe-commits
nikic wrote: @aeubanks @preames @nhaehnle Before I finish up this PR (need to update more tests and fix GlobalSplit), I'd like to have some feedback on one point. I'm currently proposing the `inrange` attribute to be relative to the result pointer, so ``` getelementptr inbounds inrange(-16,

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-07 Thread Nikita Popov via cfe-commits
https://github.com/nikic edited 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

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-07 Thread via cfe-commits
github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff 99500e8c08a4d941acb8a7eb00523296fb2acf7a 569311c751be87630bb8c7ea4042aa77e6f2fd8e --

[clang] [llvm] [IR] Change representation of getelementptr inrange (PR #84341)

2024-03-07 Thread Nikita Popov via cfe-commits
https://github.com/nikic created https://github.com/llvm/llvm-project/pull/84341 As part of the [migration to ptradd](https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699), we need to change the representation of the `inrange` attribute, which is used for vtable