On 16/08/18 12:34, Jan Beulich wrote: >>>> On 16.08.18 at 12:42, <andrew.coop...@citrix.com> wrote: >> On 16/08/18 10:55, Roger Pau Monné wrote: >>> On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote: >>>> @@ -112,6 +125,11 @@ static void __init arch_init_ideal_nops(void) >>>> ideal_nops = k8_nops; >>>> break; >>>> } >>>> + >>>> +#ifdef HAVE_AS_NOP_DIRECTIVE >>>> + if ( memcmp(ideal_nops[ASM_NOP_MAX], toolchain_nops, ASM_NOP_MAX) == >>>> 0 ) >>>> + toolchain_nops_are_ideal = true; >>>> +#endif >>> You are only comparing that the biggest nop instruction (9 bytes >>> AFAICT) generated by the assembler is what Xen believes to be the more >>> optimized version. What about shorter nops? >> They are all variations on a theme. >> >> For P6 nops, its the 0f 1f root which is important, which takes a modrm >> byte. Traditionally, its always encoded with eax and uses redundant >> memory encodings for longer instructions. >> >> I can't think of any way of detecting if the optimised nops if the >> toolchain starts using alternative registers in the encoding, but I >> expect this case won't happen in practice. > It's not just the register encoding, but also the maximum single-insn > length that gets generated. Recall that until not very long ago we > had up to 8-byte NOP insns only? The view on the mod (as in ModRM) > usage may vary over time, as may the view on which or how many > prefixes are reasonable to have.
Strictly speaking, the ORM says "encode the least-recently live register", because all the hint nops are still subject to reg/reg dependencies. However, we definitely can't take advantage of this, nor can the assembler. Compilers can't either, because the exact length of the nop depends on other relocations. Furthermore, the perf improvement from doing this would be fractional. IOW, I don't expect we'll realistically see encodings other than the exact byte layout described in the ORM. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
