> According to the Intel optimization manual, using EBP, RBP, or R13 as the base address will make LEA slower.
Now that's odd. What is special about those registers, that code using them can end up slower than the others?
Now that's odd. What is special about those registers, that code using them can end up slower than the others?
Since x86 supports complex but useful addressing, the AGU was made fast so memory operations wouldn't be dog slow.
The LEA exploits this resource for computation rather than "just" for addressing memory, for example:
lea eax, [ecx+eax*2-30h]
For some reason, the AGU seems incapable of dealing with those registers as base I guess.
[1]: https://gmplib.org/~tege/x86-timing.pdf
[2]: http://www.nynaeve.net/?p=64 (point 3)
LEAs are calculated on ALU execution units like other ALU ops. r13 and rbp are special because the usual way of encoding those registers in an indexed addressing mode without an offset was repurposed instead for another mode: offset only or RIP-relative in x86-64.
This affected only ebp in x86-32 but also r13 in x86-64 because of the way the instruction was encoded.
As a result, if you want to use rbp as a base, you need to use an explicit offset (which can be zero) and that ends of triggering the "three source rule" for slow LEA in the case of indexed addressing, even though you have included any offset in the assembly.
The PBLENDVB case is interesting: the VEX-encoded variant takes 2 uops in every uarch, but 1 uops (since Skylake) in the non-VEX encoded variant that takes XMM0 as a hardcoded input.
My guess is that it wasn't an execution or rename limit, since PBLENDVB should be "just as hard", but a decode or (pre-rename) uop format limit: i.e., the uop format in the IDQ couldn't handle three variable inputs, but the implicit xmm0 is fine (doesn't take any space). Or the decoders couldn't handle it. Still, once 3-input stuff like FMA did appear I don't know why it wasn't fixed. Possibly FMA has special handling...
Thanks for the detailed correction.