-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
target: default to the medium code model on LoongArch targets #120661
Conversation
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. [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
(rustbot has picked a reviewer for you, use r? to override) |
These commits modify compiler targets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
@bors r=heiher,Nilstrieb |
…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][1] 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. [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
…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 equality `impl`s) - 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. |
…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 equality `impl`s) - 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
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. |
…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 equality `impl`s) - 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
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][1] 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. [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
ha, it was rolled up already^^ |
I'm OK with this PR, now we can spend our time more efficiently by implementing call36 -> bl relaxation in Binutils and LLVM anyway :). |
…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 [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models [2]: rust-lang#121289 (comment)
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 [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models [2]: rust-lang#121289 (comment)
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:
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.