Remove inline assembly from hint::spin_loop

[gnzlbg]

This PR removes the inline assembly which was not required since these
instructions are available in core::arch, and extends support of
the spin_loop hint to arm targets with the v6 feature which also
support the yield instruction.

[rust-highfive]

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

[Fanael]

The claim that pause is undefined is incorrect: pause is defined in a way that makes it a harmless NOP on all earlier CPUs, and is even explicitly defined as such in Intel manuals:

This instruction was introduced in the Pentium 4 processors, but is backward compatible with all IA-32 processors. In earlier IA-32 processors, the PAUSE instruction operates like a NOP instruction.

[gnzlbg]

Indeed. I suppose that this means that an assembler, like the LLVM assembler, cannot deduce from seeing pause that SSE2 is enabled, is that correct?

When trying to compile libcore with non-LLVM backends (like Cranelift), inline assembly is problematic (e.g. Cranelift does not support LLVM inline assembly). The _mm_pause intrinsic is better, but calling that intrinsic is UB on hardware that does not support SSE2.

@Fanael is there an advantage of emitting pause over not emitting anything on targets without SSE2 ? If the answer is no, then we can leave it like this. If the answer is yes, we might need to add a nop intrinsic to core::arch and call it on such targets instead.

[Fanael]

The _mm_pause intrinsic is better, but calling that intrinsic is UB on hardware that does not support SSE2.

It really is not. The intrinsic is defined in Intel manuals in terms of the instruction itself (the intrinsics in LLVM and everywhere else just follow Intel definitions), and LLVM itself doesn't require SSE2 for pause: llvm-mirror/llvm@a8f11c1

@Fanael is there an advantage of emitting pause over not emitting anything on targets without SSE2 ? If the answer is no, then we can leave it like this.

Not that I know, there is no advantage on any of Intel's old microarchitectures, they just interpret it as a nop and have no special way of handling spin loops. It might be different on AMD's K7 or VIA Nehemiah, but I don't have that hardware to test, and I doubt it makes any difference anyway.

[shepmaster]

r? @alexcrichton

[gnzlbg]

It really is not.

It is in Rust, due to what appears to be a bug in the Intel C Intrinsics spec that we use for our definitions. I've opened rust-lang/stdarch#705 to track this.

Not that I know, there is no advantage on any of Intel's old microarchitectures,

Then I think I would prefer to not emit anything on those, at least until the bug in core::arch is fixed.

[nagisa]

The implementation LGTM.

@bors r+

[bors]

📌 Commit e07d163 has been approved by nagisa

[Centril]

Failed in #59300 (comment), @bors r-

[mati865]

Submodules messed up?

[gnzlbg]

Submodules messed up?

Indeed, thanks!

[alexcrichton]

@bors: r=nagisa

[bors]

📌 Commit 830c98d has been approved by nagisa