Similar to what we do for addx. Since we're calculating b - a and
because subtraction is not communitative, we can only apply this when
source register a holds the constant.
Before:
45 8B EE mov r13d,r14d
41 83 ED 08 sub r13d,8
After:
45 8D 6E F8 lea r13d,[r14-8]
We can get away with skipping the addition when we know we're dealing
with a constant zero. Just a MOV will suffice in this case.
Once again, we don't bother to add separate handling for when overflow
is needed, because no titles would ever hit that path during my testing.
Before:
8B 7D F8 mov edi,dword ptr [rbp-8]
83 C7 00 add edi,0
After:
8B 7D F8 mov edi,dword ptr [rbp-8]
ADD has a smaller encoding for immediates that can be expressed as an
8-bit signed integer (in other words, between -128 and 127). MOV lacks
this compact representation.
Since addition allows us to swap the source registers, we can always get
the shortest sequence here by carefully checking if we're dealing with a
small immediate first. If we are, move the other source into the
destination and add the small immediate onto that. For large immediates
the reverse is preferrable.
Before:
41 BE 40 00 00 00 mov r14d,40h
44 03 75 A8 add r14d,dword ptr [rbp-58h]
After:
44 8B 75 A8 mov r14d,dword ptr [rbp-58h]
41 83 C6 40 add r14d,40h
Before:
44 8B 7D F8 mov r15d,dword ptr [rbp-8]
41 81 C7 00 68 00 CC add r15d,0CC006800h
After:
41 BF 00 68 00 CC mov r15d,0CC006800h
44 03 7D F8 add r15d,dword ptr [rbp-8]
When the source registers are a simple register and a constant zero and
overflow isn't needed, emitting LEA is kinda silly.
This will occasionally save a single byte for certain registers due to
how x86 encoding works. More importantly, LEA takes up execution
resources while MOV does not.
Before:
41 8D 7D 00 lea edi,[r13]
After:
41 8B FD mov edi,r13d
When the destination register matches a source register, the other
source register contains zero, and overflow isn't needed, the
instruction becomes a nop and we don't need to emit anything.
We could add specialized handling for the case where overflow is needed,
but none of the titles I tried would hit this path.
Before:
83 C7 00 add edi,0
After:
No functional change, just simplify some repeated logic in the case
where we're dealing with exactly one immediate and one simple register
when overflow isn't needed.
Due to the way the ModRM encoding works on x86, memory addressing
combinations involving RBP or R13 need an additional byte for an 8-bit
displacement of zero.
However, this was also applied in cases where it is unnecessary,
effectively wasting a byte.
- MatR with RSP or R12
8B 44 24 00 mov eax,dword ptr [rsp]
8B 04 24 mov eax,dword ptr [rsp]
- MRegSum with base != RBP or R13
46 8D 7C 37 00 lea r15d,[rdi+r14]
46 8D 3C 37 lea r15d,[rdi+r14]
- MComplex without offset
8B 4C CA 00 mov ecx,dword ptr [rdx+rcx*8]
8B 0C CA mov ecx,dword ptr [rdx+rcx*8]
Test the behavior of OpArg::WriteRest by using MOV with the various
addressing modes (MatR, MRegSum, etc.) in the source operand.
Both the instruction and the instruction length are validated.
The old logic would always emit LEA when both sources are in a register
and OE is disabled. However, ADD is still preferable when one of the
sources matches the destination.
Before:
45 8D 6C 35 00 lea r13d,[r13+rsi]
After:
44 03 EE add r13d,esi
Identical, except that this used a temporary register as scratch instead
of RCX. round_long_acc now no longer needs scratch, so we can
deduplicate the logic.
Prior to this commit, the emitter would emit a 7-byte instruction when
loading a 32-bit immediate to a 64-bit register.
0: 48 c7 c0 ff ff ff 7f mov rax,0x7fffffff
With this change, it will check if it can instead emit a load to a
32-bit register, which takes only 5 or 6 bytes.
0: b8 ff ff ff 7f mov eax,0x7fffffff
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de 00 movabs rax,0xdeadbeef
7: 00 00 00
With this change, it will instead rely on the fact that on x64 writes to
32-bit registers are automatically zero extended to 64-bits, allowing
us to emit a 5 or 6-bytes instruction with the same effect for certain
immediates.
0: b8 ef be ad de mov eax,0xdeadbeef
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de ff movabs rax,0xffffffffdeadbeef
7: ff ff ff
With this change, it will instead emit a 7-byte instruction when it is
possible to express the 64-bit immediate using a signed 32-bit value.
0: 48 c7 c0 ef be ad de mov rax,0xffffffffdeadbeef