Re: [PATCH] x86/build: Use new .nops directive when available

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] x86/build: Use new .nops directive when available
Date: Thu, 16 Aug 2018 12:48:48 +0100	[thread overview]
Message-ID: <1cc5b4a4-2b56-1fdb-71af-17ad4a4a424d@citrix.com> (raw)
In-Reply-To: <5B75614102000078001DEDD9@prv1-mh.provo.novell.com>

On 16/08/18 12:34, Jan Beulich wrote:
>>>> On 16.08.18 at 12:42, <andrew.cooper3@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