Remove avx512dq and avx512vl implication for avx512fp16 by sayantn · Pull Request #140389 · 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
Conversation20 Commits2 Checks6 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 }})
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
Relevant to the library team, which will review and decide on the PR/issue.
Area: SIMD (Single Instruction Multiple Data)
Area: Enabling/disabling target features like AVX, Neon, etc.
Target: x86 processors, 32 bit (like i686-*) (IA-32)
Target: x86-64 processors (like x86_64-*) (also known as amd64 and x64)
labels
⚠️ Warning ⚠️
- Some commits in this PR modify submodules.
Relevant to the library team, which will review and decide on the PR/issue.
label
This comment has been minimized.
This was referenced
Apr 28, 2025
This comment has been minimized.
cc @a4lg there seems to be some doc errors in the is_riscv_feature_detected macro. Could you look into the pls.
PS: I am quite confused how they weren't caught in the stdarch CI
On hindsight, this seems like a bug in rustdoc with cg_gcc. Still I am retrying the CI
cc @rust-lang/rustdoc @rust-lang/wg-gcc-backend
edit: not spurious
This comment has been minimized.
@sayantn
That's odd.
It seems the Linkcheck tool on the CI does its own job and the error itself seems valid.
However, multiple references to a single footnote is mandatory for simplicity of the new macro documentation with the platform guide.
And I thought this is allowed. While duplicate ID for footnote references is not ideal (of course) but at least tested in tests/rustdoc/footnote-reference-in-footnote-def.rs which has two duplicate IDs on footnote references to [^a].
So I suppose this is a rustdoc bug to be fixed (give each reference to a footnote unique ID as a long term solution).
If you prefer the short term solution to pass CI, you may revert rust-lang/stdarch#1779.
I created a rustdoc PR #140434 (implementing it was easier than I thought) to enable adopting rust-lang/stdarch#1779 in the future. I'm not sure whether adoption of this PR will result in immediate success (considering the default stage for building docs (stage 0), it might not be immediate) but I hope this is accepted.
This comment has been minimized.
a4lg approved these changes Apr 30, 2025
Will the recent changes to the bootstrapping process help this? I am talking about #119899
I'm glad to see that this change is working! (I miss carefully designed tables and guides though)
Nice, I will ask someone to start a try job to further make sure nothing is breaking
update: try runs are not needed, as most tests are already done. we don't need to do crater runs because this is (still) unstable
I'm glad to see that this change is working! (I miss carefully designed tables and guides though)
We can re-update stdarch with your PR after the Rustdoc fix is merged, and do another stdarch update. In the meantime, could you re-open that PR so that we don't forget about it? Thanks
@sayantn I filed a new issue on stdarch instead (rust-lang/stdarch#1793).
This is because merged PR cannot be reopened and re-opening closed PR requires effectively substituting everything in the PR.
📌 Commit 7443d03 has been approved by Amanieu
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
VlaDexa added a commit to VlaDexa/rust that referenced this pull request
Remove avx512dq and avx512vl implication for avx512fp16
According to Intel, avx512fp16 requires only avx512bw, but LLVM also enables avx512vl and avx512dq when avx512fp16 is active. This is relic code, and will be fixed in LLVM soon. We should remove this from Rust too asap, especially before the stabilization of AVX512
Related:
@rustbot label O-x86_64 O-x86_32 A-SIMD A-target-feature T-compiler -T-libs
r? @Amanieu
Update: the LLVM fix has been merged
cc @rust-lang/wg-llvm will it be possible to update the rustc llvm version to something after llvm/llvm-project#137450
bors added a commit to rust-lang-ci/rust that referenced this pull request
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#140389 - sayantn:avx512fp16, r=Amanieu
Remove avx512dq and avx512vl implication for avx512fp16
According to Intel, avx512fp16 requires only avx512bw, but LLVM also enables avx512vl and avx512dq when avx512fp16 is active. This is relic code, and will be fixed in LLVM soon. We should remove this from Rust too asap, especially before the stabilization of AVX512
Related:
@rustbot label O-x86_64 O-x86_32 A-SIMD A-target-feature T-compiler -T-libs
r? @Amanieu
Update: the LLVM fix has been merged
cc @rust-lang/wg-llvm will it be possible to update the rustc llvm version to something after llvm/llvm-project#137450
Labels
Area: SIMD (Single Instruction Multiple Data)
Area: Enabling/disabling target features like AVX, Neon, etc.
Target: x86 processors, 32 bit (like i686-*) (IA-32)
Target: x86-64 processors (like x86_64-*) (also known as amd64 and x64)
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.