Add a high latency "feature" (hazard) for specific shift instruction operands on Alder Lake and generic x86-64 tunings

[chandlerc]

See the detailed discussion:
https://tavianator.com/2025/shlx.html

And some added details:
https://lobste.rs/s/1hbwkk/alder_lake_shlx_anomaly

Basically, when the shift instruction is set using the wrong kind of instruction, it causes a 3x throughput hit.

There should always be other ways to encode this and so it seems worth avoiding in the x86 backend, at least when tuning for Alder Lake or a generic x86 CPU.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Chandler Carruth (chandlerc)

See the detailed discussion: https://tavianator.com/2025/shlx.html

And some added details:
https://lobste.rs/s/1hbwkk/alder_lake_shlx_anomaly

Basically, when the shift instruction is set using the wrong kind of instruction, it causes a 3x throughput hit.

There should always be other ways to encode this and so it seems worth avoiding in the x86 backend, at least when tuning for Alder Lake or a generic x86 CPU.

[tavianator]

I wrote up an explanation here of exactly when it seems to be triggered: https://tavianator.com/2025/shlxplained.html

[RKSimon]

@tavianator I don't suppose you found any instruction that will force-resolve the offset or do multiple uses of the register independently resolve on the fly? Other (rubbish) options include explicitly masking the shift amount (AND %REG32, $BW-1) I guess?

[tavianator]

Many things work, including mov rcx, rcx

[tavianator]

Basically, when the shift instruction is set using the wrong kind of instruction, it causes a 3x throughput hit.

It's a 3× latency hit, only a 2× throughput hit. (Source: https://news.ycombinator.com/item?id=42597672) It also affects bzhi and bextr apparently.

Apparently this issue also affects Lion Cove, though the immediate range is reduced to [-512, 511]. (Source: https://x.com/__mintsuki/status/1875667635846967467)

[RKSimon]

Many things work, including mov rcx, rcx

Wow, so if we inserted a 64-bit reg self-move (of the shift amount) before the shift/rotate instruction for -march=alderlake targets the regressions would go away? :|

[tavianator]

Wow, so if we inserted a 64-bit reg self-move (of the shift amount) before the shift/rotate instruction for -march=alderlake targets the regressions would go away? :|

It's not just the shift count that matters, both shift input operands are affected.

Yes you could just add mov rcx, rcx before the shift if rcx is affected, but it's not free (self-move doesn't use the renamer, which is why it even works here, but it also wastes time). It would be better to just select a different way to set the input register.

For shift counts this should be very easy: only the low 6 bits matter anyway, so just use a 32 bit op instead of a 64-bit one (e.g. add ecx, 1 instead of add rcx, 1). This is better for code size anyway. For the shifted value, it might be a little more challenging to avoid.

[RKSimon]

Hmm - we should already be reducing i64 math if its representable as i32 - do you have examples of where it isn't?

[tavianator]

Seems like LLVM is good at that. GCC not so much: https://godbolt.org/z/qf9W1r97P

[ValeZAA]

BTW, I have Lion Cove/ Arrow lake.

I can check whether 11 bit buffer is now 10 bit buffer. But someone has to write me a benchmark to compile on WSLv1. Or Visual studio.