target: default to the medium code model on LoongArch targets by xen0n · Pull Request #120661 · 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
Conversation12 Commits1 Checks0 Files changed
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 }})
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
- we do not want to ask users to recompile std if they are to build such software,
- objects compiled with larger code models can be linked with those with smaller code models without problems, and
- the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 1, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
- we do not want to ask users to recompile std if they are to build such software,
- objects compiled with larger code models can be linked with those with smaller code models without problems, and
- the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
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
also cc @jiegec -- after this patch is released and the new Rust version picked up by Chromium, the downstream Rust code-model change can be dropped from the patchset.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
📌 Commit 35dad14 has been approved by heiher,Nilstrieb
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…r,Nilstrieb
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
- we do not want to ask users to recompile std if they are to build such software,
- objects compiled with larger code models can be linked with those with smaller code models without problems, and
- the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
bors added a commit to rust-lang-ci/rust that referenced this pull request
…iaskrgr
Rollup of 9 pull requests
Successful merges:
- rust-lang#113833 (
std::error::Error-> Trait Implementations: lifetimes consistency improvement) - rust-lang#115386 (PartialEq, PartialOrd: update and synchronize handling of transitive chains)
- rust-lang#116284 (make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern)
- rust-lang#118960 (Add LocalWaker and ContextBuilder types to core, and LocalWake trait to alloc.)
- rust-lang#120384 (Use
<T, U>for array/slice equalityimpls) - rust-lang#120518 (riscv only supports split_debuginfo=off for now)
- rust-lang#120619 (Assert that params with the same index have the same name)
- rust-lang#120657 (Remove unused struct)
- rust-lang#120661 (target: default to the medium code model on LoongArch targets)
r? @ghost
@rustbot modify labels: rollup
Hmm, why not just build std with the medium code model and leave the default normal? Then the large software should use -C code-model=medium explicitly.
bors added a commit to rust-lang-ci/rust that referenced this pull request
…iaskrgr
Rollup of 8 pull requests
Successful merges:
- rust-lang#113833 (
std::error::Error-> Trait Implementations: lifetimes consistency improvement) - rust-lang#115386 (PartialEq, PartialOrd: update and synchronize handling of transitive chains)
- rust-lang#116284 (make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern)
- rust-lang#118960 (Add LocalWaker and ContextBuilder types to core, and LocalWake trait to alloc.)
- rust-lang#120384 (Use
<T, U>for array/slice equalityimpls) - rust-lang#120518 (riscv only supports split_debuginfo=off for now)
- rust-lang#120657 (Remove unused struct)
- rust-lang#120661 (target: default to the medium code model on LoongArch targets)
r? @ghost
@rustbot modify labels: rollup
Hmm, why not just build std with the medium code model and leave the default normal? Then the large software should use -C code-model=medium explicitly.
That would be better but I don't know if this can be easily done (I investigated for one or two hours last night but didn't find out; maybe it is possible and it's just me forgetting), or if there would still be missing cases.
Hmm, why not just build std with the medium code model and leave the default normal? Then the large software should use -C code-model=medium explicitly.
That would be better but I don't know if this can be easily done (I investigated for one or two hours last night but didn't find out; maybe it is possible and it's just me forgetting), or if there would still be missing cases.
I believe using 'cargo build-std' in the current project recompiles the standard library, potentially changing its code model. But this relies on unstable features, and users might not be familiar with it. I've received feedback on default code models from users before, and if a small performance trade-off can improve the user experience, I think it's worthwhile. Thanks.
We could default to small and build the distributed std with medium, if you prefer that. You'd implement this logic in src/bootstrap, look at fn cargo.
@bors r-
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
bors added a commit to rust-lang-ci/rust that referenced this pull request
…iaskrgr
Rollup of 8 pull requests
Successful merges:
- rust-lang#113833 (
std::error::Error-> Trait Implementations: lifetimes consistency improvement) - rust-lang#115386 (PartialEq, PartialOrd: update and synchronize handling of transitive chains)
- rust-lang#116284 (make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern)
- rust-lang#118960 (Add LocalWaker and ContextBuilder types to core, and LocalWake trait to alloc.)
- rust-lang#120384 (Use
<T, U>for array/slice equalityimpls) - rust-lang#120518 (riscv only supports split_debuginfo=off for now)
- rust-lang#120657 (Remove unused struct)
- rust-lang#120661 (target: default to the medium code model on LoongArch targets)
r? @ghost
@rustbot modify labels: rollup
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#120661 - xen0n:loong-medium-cmodel, r=heiher,Nilstrieb
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
- we do not want to ask users to recompile std if they are to build such software,
- objects compiled with larger code models can be linked with those with smaller code models without problems, and
- the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
ha, it was rolled up already^^
well, if you want to change it back, feel free to make a new PR
ha, it was rolled up already^^ well, if you want to change it back, feel free to make a new PR
I'm OK with this PR, now we can spend our time more efficiently by implementing call36 -> bl relaxation in Binutils and LLVM anyway :).
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…iler-errors
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 1, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
- we do not want to ask users to recompile std if they are to build such software,
- objects compiled with larger code models can be linked with those with smaller code models without problems, and
- the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
Relands [2]: rust-lang#120661
[2]: rust-lang#121289 (comment)
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#130266 - heiher:loong-medium-cmodel, r=compiler-errors
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 1, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
- we do not want to ask users to recompile std if they are to build such software,
- objects compiled with larger code models can be linked with those with smaller code models without problems, and
- the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
Relands [2]: rust-lang#120661
[2]: rust-lang#121289 (comment)
Labels
Status: This is awaiting some action (such as code changes or more information) from the author.
Relevant to the compiler team, which will review and decide on the PR/issue.