Hacker News Reader

Comment by BeeOnRope | Hacker News Reader

Worth noting that whether intentional or not, this would be easy to miss and unlikely to move benchmark numbers since compilers won't generate instructions like this: they would use the eax form which is 1 byte shorter and functionally equivalent.

Even some assemblers will optimize this for you.

View on HN

It's possible to get gcc to generate sequences that would trigger this: https://godbolt.org/z/rYKqPxn7b

The godbolt paste I'm looking at shows GCC generating a SAL with 8 bit shift (CL), not a SHLX with 64-bit shift (RCX).

GCC will generate the shlx instruction if you add the -mbmi2 flag to your build options. For example, you can see this in action here: https://godbolt.org/z/asb1fxos5.

It's true, I was considering only the original mov rax, 1 case, which I'm pretty sure compilers don't generate: it's just a useless encoding of mov eax, 1.

Given that 64-bit immediate math also causes this though, compilers might generate it (I think this is a minor missed optimization by gcc though: it could have used add eax, 1 instead.

SHL suffers from the same latency issue as SHLX it turns out

SAL as well? (And anyway this example seems to be shifting by the low 8 bits of RCX (CL), not the full width register.)

SAL and SHL are synonyms, they have the same encoding. SHL only accepts CL as the count register, there's no other form that takes a variable shift count

Ahh, thanks, I didn't make that connection.

Intel shifts anyway mask out higher bits of CL, this hurts sometimes e.g. when you need to shift by 1..64 bits

Funny thing to double-check: are these encodings correctly specifying a 64-bit operand? Maybe everyone's compilers are subtly wrong D:

edit: It looks like VEX.W is set in the encoding from the uops.info tests ¯\_(ツ)_/¯

Reply on news.ycombinator.com