With only 1 uop / 1c latency on the critical path of the target register:
# target=rax extra source=rcx
mov edx, ecx ; no latency
and edx, 0 ; BMI1 ANDN could mov+and in 1 uop, port 1 or 5 only on SnB-family (Ryzen: any)
or rax, rdx
AND with zero is not special-cased as a dep-breaking zeroing idiom on any CPUs, AFAIK.
front-end uops: 3 (or 2 with BMI1). Latency:
- from rcx to rax: 2c (with mov-elimination or BMI1).
- from rax(input) to rax(output): 1c
With a zeroed register, if it's ok to couple all the dep chains into that one register (unlike the ANDN version that only reads an all-ones register):
and edx, ecx # 0 &= ecx
or rax, rdx # rax |= 0
To test a function's latency (not throughput) but still feed it the same input repeatedly:
.loop:
call func ; arg in RDI, return in RAX
mov rdi, rbx ; arg for next iter, off the critical path
and eax, 0 ; 1c latency
or rdi, rax ; 1c latency
jmp .loop
If the function is pure, we can do 1c / 1uop
Actually it just has to return a known value for a given input. This also works if its impurities are limited to having other side-effects / outputs.
Instead of XOR twice after getting the result, set things up so we already have an XOR that we can unscramble with only one more XOR. Or use addition because LEA lets us copy-and-add in one instruction, saving a mov that wouldn't be on the critical path.
mov rdi, rbx ; original input
call func
sub rbx, rax ; RBX = input - output
.loop:
call func
lea rdi, [rbx + rax] ; RDI = (input-output) + output = input
jmp .loop
@RossRidge's suggestion is only 1 uop on SnB-family CPUs, but only runs on port 1:
shld rax, rcx, 0
3c latency, 1 uop for port 1 on HSW/SKL. Agner Fog reports 1c latency for IvB, but 3c for HSW/BDW/SKL.
shld r,r,i is 2 uops on older Intel, and significantly slower on AMD, like 6 uops / 3c latency on Piledriver / Ryzen.
Note that instlatx64 reports 1c latency / 0.5c throughput for shld/shrd on Haswell/Skylake (like single-register shifts), but I tested myself and it's definitely 3c latency / 1c throughput. Reported as an instlatx64 bug on their github page.
SHLD could also be interesting for copying a 32-bit register with a dependency on another. e.g. @BeeOnRope describes wanting to call a function repeatedly with the same input value in RDI, but with a dependency on the result in RAX. If we only care about EDI, then
; RBX = input<<32
call func
mov edi, eax ; 0 latency with mov-elimination
shld rdi, rbx, 32 ; EDI = the high 32 bits of RBX, high bits of RDI = old EDI.
Of course that's pointless vs. this, which doesn't need mov-elimination
call func
mov rdi, rbx ; off critical path
shld rdi, rax, 0 ; possibly 1c latency on SnB / IvB. 3 on HSW/SKL
A modification of @DavidWholford's suggestion works, too:
test ecx,ecx ; CF=0, with a false dependency on RCX
adc rax, 0 ; dependent on CF
2 uops on Haswell/Broadwell/Skylake and AMD. 3 uops on Intel P6-family, and maybe SnB/IvB. Latency:
- from rcx to rax: 2c on HSW and later, 3 with 2-uop adc
- from rax to rax: 1c on HSW and later, 2 with 2-uop adc
ADC on Haswell and earlier is normally 2 uops, but adc with immediate 0 is special-cased on Haswell to only be 1 uop / 1c. adc eax,0 is always 2c latency on Core 2. The first uarch with this optimization might be SnB, but hopefully we get an answer on Which Intel microarchitecture introduced the ADC reg,0 single-uop special case?
test clears CF regardless of the value, but I think (untested) that CF still carries a dependency on the source register. If not, then perhaps use TEST / ADOX could be useful on Broadwell and later. (Because CF is renamed separately on most CPUs, but OF might only be part of the same bundle as ZF / SF and other flags that do depend on the AND result.)
