Re: [PATCH] RFC x86/msr: Use WRMSRNS $imm when available

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.08.2025 12:16, Andrew Cooper wrote:
> On 11/08/2025 11:06 am, Jan Beulich wrote:
>> On 11.08.2025 11:50, Andrew Cooper wrote:
>>> On 11/08/2025 9:16 am, Jan Beulich wrote:
>>>> On 09.08.2025 00:20, Andrew Cooper wrote:
>>>>> +        "mov %%rax, %%rdx\n\t"
>>>>> +        "shr $32, %%rdx\n\t"
>>>>> +        ".byte 0x0f,0x01,0xc6", X86_FEATURE_WRMSRNS,
>>>>> +
>>>>> +        [msr] "i" (msr), "a" (val) : "rcx", "rdx");
>>>>         [msr] "i" (msr), "a" (val), "c" (msr) : "rdx");
>>>>
>>>> allowing the compiler to actually know what's put in %ecx? That'll make
>>>> original and 2nd replacement code 10 bytes, better balancing with the 9
>>>> bytes of the 1st replacement. And I'd guess that the potentially dead
>>>> MOV to %ecx would be hidden in the noise as well.
>>> I considered that, but what can the compiler do as a result of knowing %ecx?
>> For example ...
>>
>>> That said, we do need an RDMSR form (which I desperately want to make
>>> foo = rdmsr(MSR_BAR) but my cleanup series from 2019 got nowhere), and
>>> in a read+write case I suppose the compiler could deduplicate the setup
>>> of %ecx.
>> ... this. But also simply to use a good pattern (exposing as much as possible
>> to the compiler), so there are more good instances of code for future cloning
>> from. (In size-optimizing builds, the compiler could further favor ADD/SUB
>> over MOV when the two MSRs accessed are relatively close together.)
> 
> I have seen the compiler do this in the past, but couldn't reproduce it
> for this work.
> 
> We specifically do not want any conversion to ADD/SUB, because that
> takes our "close to a nop" and makes it no so.

Imo when size optimizing, size matters and "close-to-a-NOP" doesn't (as much).

Jan