Stop using LLVM struct types for array/pointer offset GEPs by erikdesjardins · Pull Request #122325 · rust-lang/rust (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
...and just use a byte array with the same size as the element type instead. This avoids depending on LLVM's struct layout to determine the size of the array/pointer element.
Spiritually split out from #121577.
r? @nikic
This avoids depending on LLVM's struct types to determine the size of the array/pointer element.
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
This comment has been minimized.
bors added a commit to rust-lang-ci/rust that referenced this pull request
Stop using LLVM struct types for array/pointer offset GEPs
...and just use a byte array with the same size as the element type instead. This avoids depending on LLVM's struct layout to determine the size of the array/pointer element.
Spiritually split out from rust-lang#121577.
r? @nikic
This comment has been minimized.
☀️ Try build successful - checks-actions
Build commit: 7ba692d (7ba692d484ffb437afc774f11309f398ff2ab358)
This comment has been minimized.
Finished benchmarking commit (7ba692d): comparison URL.
Overall result: ❌✅ regressions and improvements - no action needed
Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.
@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression
Instruction count
This is a highly reliable metric that was used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | - | - | 0 |
| Regressions ❌ (secondary) | 1.5% | [1.5%, 1.5%] | 1 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | -1.8% | [-2.4%, -1.4%] | 4 |
| All ❌✅ (primary) | - | - | 0 |
Max RSS (memory usage)
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 2.4% | [1.0%, 3.7%] | 12 |
| Regressions ❌ (secondary) | 2.7% | [1.6%, 3.8%] | 23 |
| Improvements ✅ (primary) | -2.0% | [-2.0%, -2.0%] | 1 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | 2.1% | [-2.0%, 3.7%] | 13 |
Cycles
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | - | - | 0 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | -9.6% | [-9.9%, -9.3%] | 4 |
| All ❌✅ (primary) | - | - | 0 |
Binary size
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | - | - | 0 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | -0.1% | [-0.2%, -0.0%] | 11 |
| Improvements ✅ (secondary) | -0.2% | [-0.2%, -0.2%] | 1 |
| All ❌✅ (primary) | -0.1% | [-0.2%, -0.0%] | 11 |
Bootstrap: 647.708s -> 643.848s (-0.60%)
Artifact size: 309.95 MiB -> 309.65 MiB (-0.10%)
GCC uses a start/end pointer instead of the index-based loop on LLVM, so it has a "GEP" here that needs to be converted for consistency with project_index
I'm not sure this is a particularly useful change to make at this time.
This isn't really about ptradd anymore. I want to get to a point where we never use LLVM struct types except for scalarpair returns†, which feels like it's almost within reach. That should make it a lot harder for us to accidentally leak Rust/LLVM implementation details into our ABIs, or to create completely broken ABIs like wasm32-unknown-unknown. (In this specific case, it also just feels silly that we generate these full-fidelity types, and then the only thing LLVM does is add up all the fields to compute the size, something we already did.)
But given that this pattern is likely to get a proper untyped representation in the future (with scaled ptradd or something), I'm fine if you want to wait for that.
† ...and a few unfortunate special cases: volatile load/store, unadjusted ABI, wasm32-unknown-unknown, and surely some things I haven't found yet that won't be easily changed.
@nikic Do you think we should wait for a proper untyped representation in LLVM IR as @erikdesjardins mentions or should we consider merging this?
I think it's better to wait. LLVM still has some source element type dependent logic for variable index GEPs, and I don't think there's much benefit to making this change early.
Status: Blocked on something else such as an RFC or other implementation work.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Labels
Status: Blocked on something else such as an RFC or other implementation work.
Relevant to the compiler team, which will review and decide on the PR/issue.