Set all bits in CPU register to 1 efficiently
For most architectures with fixed-width instructions, the answer will probably be a boring one instruction mov of a sign-extended or inverted immediate, or a mov lo/high pair. e.g. on ARM, mvn r0, #0 (move-not). See gcc asm output for x86, ARM, ARM64, and MIPS, on the Godbolt compiler explorer. IDK anything about zseries asm or machine code.
In ARM, eor r0,r0,r0 is significantly worse than a mov-immediate. It depends on the old value, with no special-case handling. Memory dependency-ordering rules prevent an ARM uarch from special-casing it even if they wanted to. Same goes for most other RISC ISAs with weakly-ordered memory but that don't require barriers for memory_order_consume (in C++11 terminology).
x86 xor-zeroing is special because of its variable-length instruction set.
Historically, 8086 xor ax,ax was fast directly because it was small. Since the idiom became widely used (and zeroing is much more common than all-ones), CPU designers gave it special support, and now xor eax,eax is faster than mov eax,0 on Intel Sandybridge-family and some other CPUs, even without considering direct and indirect code-size effects. See What is the best way to set a register to zero in x86 assembly: xor, mov or and? for as many micro-architectural benefits as I've been able to dig up.
If x86 had a fixed-width instruction-set, I wonder if mov reg, 0 would have gotten as much special treatment as xor-zeroing has? Perhaps, because dependency-breaking before writing the low8 or low16 is important.
The standard options for best performance:
mov eax, -1: 5 bytes, using themov r32, imm32encoding. (There is no sign-extendingmov r32, imm8, unfortunately). Excellent performance on all CPUs. 6 bytes for r8d-r15d (REX prefix).mov rax, -1: 7 bytes, using themov r/m64, sign-extended-imm32encoding. (Not the REX.W=1 version of theeaxversion. That would be 10-bytemov r64, imm64). Excellent performance on all CPUs.
The weird options that save some code-size usually at the expense of performance:
(See also Tips for golfing in x86/x64 machine code)
xor eax,eax/dec rax(ornot rax): 5 bytes (4 for 32-biteax, or 3 bytes in 32-bit mode where 1-bytedec eaxexists. 64-bit mode used those 1-byte instructions as REX prefixes). Downside: two uops for the front-end. Still only one unfused-domain uop for the scheduler/execution units on recent Intel where xor-zeroing is handled in the front-end.mov-immediate always needs an execution unit. (But integer ALU throughput is rarely a bottleneck for instructions that can use any port; the extra front-end pressure is the problem)xor ecx,ecx/lea eax, [rcx-1]5 bytes total for 2 constants (6 bytes forrax): leaves a separate zeroed register. If you already want a zeroed register, there is almost no downside to this.leacan run on fewer ports thanmov r,ion most CPUs, but since this is the start of a new dependency chain, the CPU can run it in any spare execution-port cycle after it issues.The same trick works for any two nearby constants, if you do the first one with
mov reg, imm32(or push imm8/pop) and the second withlea r32, [base + disp8]. disp8 has a range of -128 to +127, otherwise you need adisp32.After a loop you may have a known-zero register, but LEA relative to it creates a false dependency, while mov-immediate wouldn't. Branch prediction + speculative exec can break control dependencies, although loop branches often mispredict their last iteration unless the trip count is low.
or eax, -1: 3 bytes (4 forrax), using theor r/m32, sign-extended-imm8encoding. Downside: false dependency on the old value of the register.push -1/pop rax: 3 bytes. Slow but small. Recommended only for exploits / code-golf. Works for any sign-extended-imm8, unlike most of the others.Downsides:
- uses store and load execution units, not ALU. (Possibly a throughput advantage in a rare cases on AMD Bulldozer-family where there are only two integer execution pipes, but decode/issue/retire throughput is higher than that. But don't try it without testing.)
- store/reload latency means
raxwon't be ready for ~5 cycles after this executes on Skylake, for example. - (Intel): puts the stack-engine into rsp-modified mode, so the next time you read
rspdirectly it will take a stack-sync uop. (e.g. foradd rsp, 28, or formov eax, [rsp+8]). - The store could miss in cache, triggering extra memory traffic. (Possible if you haven't touched the stack inside a long loop).
Vector regs are different
Setting vector registers to all-ones with pcmpeqd xmm0,xmm0 is special-cased on most CPUs as dependency-breaking (not Silvermont/KNL), but still needs an execution unit to actually write the ones. pcmpeqb/w/d/q all work, but q is slower on some CPUs and has longer machine code.
For AVX2, the ymm equivalent vpcmpeqd ymm0, ymm0, ymm0 is also the best choice. (Or b/w are equivalent, but vpcmpeqq has longer machine code.)
For AVX without AVX2 the choice is less clear: there is no one obvious best approach. Compilers use various strategies: gcc prefers to load a 32-byte constant with vmovdqa, while older clang uses 128-bit vpcmpeqd followed by a cross-lane vinsertf128 to fill the high half. Newer clang uses vxorps to zero a register then vcmptrueps to fill it with ones. This is the moral equivalent of the vpcmpeqd approach, but the vxorps is needed to break the dependency on the prior version of the register and vcmptrueps has a latency of 3. It makes a reasonable default choice.
Doing a vbroadcastss from a 32-bit value is probably strictly better than the load approach, but it is hard to get compilers to generate this.
The best approach probably depends on the surrounding code.
Fastest way to set __m256 value to all ONE bits
AVX512 compares are only available with a mask register (like k0) as the destination, so compilers are currently using vpternlogd zmm0,zmm0,zmm0, 0xff as the 512b all-ones idiom. (0xff makes every element of the 3-input truth-table a 1). This is not special-cased as dependency-breaking on KNL or SKL, but it has 2-per-clock throughput on Skylake-AVX512. This beats using a narrower dependency-breaking AVX all-ones and broadcasting or shuffling it.
If you need to re-generate all-ones inside a loop, obviously the most efficient way is to use a vmov* to copy an all-ones register. This doesn't even use an execution unit on modern CPUs (but still takes front-end issue bandwidth). But if you're out of vector registers, loading a constant or [v]pcmpeq[b/w/d] are good choices.
For AVX512, it's worth trying VPMOVM2D zmm0, k0 or maybe VPBROADCASTD zmm0, eax. Each has only 1c throughput, but they should break dependencies on the old value of zmm0 (unlike vpternlogd). They require a mask or integer register which you initialized outside the loop with kxnorw k1,k0,k0 or mov eax, -1.
For AVX512 mask registers, kxnorw k1,k0,k0 works, but it's not dependency-breaking on current CPUs. Intel's optimization manual suggests using it for generating an all-ones before a gather instruction, but recommends avoiding using the same input register as the output. This avoids making an otherwise-independent gather dependent on a previous one in a loop. Since k0 is often unused, it's usually a good choice to read from.
I think vpcmpeqd k1, zmm0,zmm0 would work, but it's probably not special-cased as a k1=1 idiom with no dependency on zmm0. (To set all 64 bits instead of just the low 16, use AVX512BW vpcmpeqb or kxnorq)
On Skylake-AVX512, k instructions that operate on mask registers only run on a single port, even simple ones like kandw. (Also note that Skylake-AVX512 won't run vector uops on port1 when there are any 512b operations in the pipe, so execution unit throughput can be a real bottleneck.)
There is no kmov k0, imm, only moves from integer or memory. Probably there are no k instructions where same,same is detected as special, so the hardware in the issue/rename stage doesn't look for k registers.
Peter's already provided a perfect answer. I just wanna mention, that it depends on the context, too.
I for once did a sar r64, 63 of a number I know will be negative in a certain case, and if not, I don't need no all bits set value. A sar has the advantage that it sets some interesting flags, although decoding 63, really?, then I could've done a mov r64, -1, too. I guess it was the flags, that let me do it anyway.
So bottom line: context. As you know, you usually delve into assembly language, because you want to process the extra knowledge you, but not the compiler has. Maybe some of your registers whose value you don't need anymore has a 1 stored (so logical true), then just neg it. Maybe somewhere earlier in your program you did a loop, then (provided it is manageable) you can arrange your register usage so a not rcx is all that's missing.