Stabilize asm! and global_asm!

[Amanieu]

Tracking issue: #72016

It's been almost 2 years since the original RFC was posted and we're finally ready to stabilize this feature!

The main changes in this PR are:

• Removing asm! and global_asm! from the prelude as per the decision in Decide whether asm! and/or global_asm! should be exported from the prelude.  #87228.
• Stabilizing the asm and global_asm features.
• Removing the unstable book pages for asm and global_asm. The contents are moved to the reference and rust by example.
  • All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example.
• Removing the automatic suggestion for using llvm_asm! instead of asm! if you're still using the old syntax, since it doesn't work anymore with asm! no longer being in the prelude. This only affects code that predates the old LLVM-style asm! being renamed to llvm_asm!.
• Updating stdarch and compiler-builtins.
• Updating all the tests.

r? @joshtriplett

[rust-highfive]

Some changes occured to rustc_codegen_gcc

cc @antoyo

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify submodules.

[Amanieu]

In case anyone's wondering: yes, I made a typo when publishing a new version of compiler-builtins.

[nbdd0121]

Would it make sense to leave the macro in the prelude unstably for easier migration?

[joshtriplett]

I just posted a set of review comments; with all of those addressed, r=me.

[bors]

☔ The latest upstream changes (presumably #91799) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

@bors r=joshtriplett

[bors]

📌 Commit 9af1f7d550300b5459fa6c4b8d6213f3003e15cf has been approved by joshtriplett

[bors]

☔ The latest upstream changes (presumably #91813) made this pull request unmergeable. Please resolve the merge conflicts.

[rylev]

This seems likely to be noise as a result of the issue tracked in rust-lang/rustc-perf#1126 -- marking as triaged, not something we should address directly.

@rustbot label +perf-regression-triaged

[FCLC]

[x86_64, AVX512]
I might be missing something in the docs, but AFAICT as of now the only supported avx512 instruction sets are the foundation set (avx512F) and the Byte and Word set (avx512BW), the implication being that the V(ector) L(ength) and D(ual) Q(uad) sets are not currently supported.

Reason I bring this up is mainly to do with the exclusion of AVX512VL. The VL set extends the foundation set (and most other sets) to be able to operate on both XMM and YMM registers, allowing for much cleaner implementations as well as faster overall code.

The reason for wanting this functionality is due the lower latency of certain AVX and AVX2 instructions that can only operate on xmm registers, but wanting the more modern and advanced instructions available under AVX512.

For example, as of now if we wanted to do a fuse multiply add on a group of 4 packed singles without avx512VL we'd have to do something along the lines of

xor/zero out all your registers
vmov zmm1, {mem pointer to 4 PS}
vfmadd132 zmm1, zmm1, zmm1; do a fuse multiply add on each of the 4 packed singles on themselves
vextractf32x4 xmm1, zmm1, 0
whatever you need to do in xmm registers
vinsertf32x4 zmm1, zmm1, xmm1, 0 ; we're back in ZMM registers for any avx512 instruction work we need to do

The VL set of extensions allows us to use AVX512 instructions directly on xmm and ymm registers, removing the need for copying back and forth between AVX1/2 registers and AVX512 registers.

This is also relevant not only because of the latency cost, but also because they may find themselves on different ports of the CPU core itself, slowing us down further.

The above would become:

vmov xmm1, {mem pointer to 4 PS}
vfmadd132 xmm1, xmm1, xmm1; do a fuse multiply add on each of the 4 packed singles on themselves
{other SIMD instructions from AVX1/2 512 or SSE all operating on xmm without extra copies}