On 07/01/2020 16:17, Wei Liu wrote:
> On Sun, Jan 05, 2020 at 10:06:08PM +0000, Andrew Cooper wrote:
>> On 05/01/2020 21:22, Wei Liu wrote:
>>> On Sun, Jan 05, 2020 at 07:08:28PM +0000, Andrew Cooper wrote:
>>>>> +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input,
>>>>> paddr_t output)
>>>>> +{
>>>>> + uint64_t status;
>>>>> +
>>>>> + asm volatile ("mov %[output], %%r8\n"
>>>>> + "call hv_hypercall_page"
>>>>> + : "=a" (status), "+c" (control),
>>>>> + "+d" (input) ASM_CALL_CONSTRAINT
>>>>> + : [output] "rm" (output)
>>>>> + : "cc", "memory", "r8", "r9", "r10", "r11");
>>>> I think you want:
>>>>
>>>> register unsigned long r8 asm("r8") = output;
>>>>
>>>> and "+r" (r8) as an output constraint.
>>> Although it is named `output`, it is really just an input parameter from
>>> Hyper-V's PoV.
>> Yes, but it is also clobbered.
>>
>> This is an awkward corner case of gnu inline assembly.
>>
>> It is not permitted to have a clobber list overlap with any input/output
>> operations, and because r8 doesn't have a unique letter, you can't do
>> the usual trick of "=r8" (discard) : "r8" (input).
>>
>> The only available option is to mark it as read and written (which is
>> "+r" in the output list), and not use the C variable r8 at any point later.
> But r8 is only listed in clobber list, so it certainly doesn't overlap
> with any input register. I fail to see what the bug (if there is any) is
> here.
%r8 is an input parameter. You have "mov %[output], %%r8" in the asm.
The way this is written causes the compiler to construct %[output] in a
register, pass it in via the sole input parameter, and behind the scenes
move it into %r8.
There is a small chance of the emitted asm being "mov %r8, %r8", and a
much larger chance of the compiler being forced to spill a different
register when it could have used %r8 in the first place.
> I think what you're asking for here is an optimisation. Is that correct?
> I don't mind changing the code. What I need is clarification here.
I'm on the fence as to whether to put in the category of optimisation,
or buggy asm.
I think the generated code will DTRT, but it is a suspicious looking
piece of assembly, so "optimisation" I guess?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
