RFC: Should x86-64 support arbitrary calling conventions?

[Richard Henderson]

On 03/25/2017 01:26 AM, H.J. Lu wrote:
> On Thu, Mar 23, 2017 at 4:14 PM, Richard Henderson <rth@twiddle.net> wrote:
>> On 03/24/2017 01:41 AM, H.J. Lu wrote:
>>>
>>> +# ifdef STATE_SAVE_MASK
>>> +       movl $STATE_SAVE_MASK, %eax
>>> +       xorl %edx, %edx
>>> +       # Clear the XSAVE Header.
>>> +       movq $0, (STATE_SAVE_OFFSET + 512)(%rsp)
>>> +       movq $0, (STATE_SAVE_OFFSET + 512 + 8)(%rsp)
>>> +       movq $0, (STATE_SAVE_OFFSET + 512 + 8 * 2)(%rsp)
>>> +       movq $0, (STATE_SAVE_OFFSET + 512 + 8 * 3)(%rsp)
>>> +       movq $0, (STATE_SAVE_OFFSET + 512 + 8 * 4)(%rsp)
>>> +       movq $0, (STATE_SAVE_OFFSET + 512 + 8 * 5)(%rsp)
>>> +       movq $0, (STATE_SAVE_OFFSET + 512 + 8 * 6)(%rsp)
>>> +       movq $0, (STATE_SAVE_OFFSET + 512 + 8 * 7)(%rsp)
>>>  # endif
>>
>>
>> You've just cleared %rdx.  Use that instead of 8*4 bytes of immediate zeros.
>>
>> Given that you have to ifdef this code into place, isn't it somewhat
>> pointless to hide xsave behind a macro in the next line?
>>
>>> +       STATE_SAVE STATE_SAVE_OFFSET(%rsp)
>>
>>
>> I think it would be clearer to inline the two save instructions instead.

That said... is there any reason not to use XSAVEC, if supported?

 From the description, it avoids saving components for which XINUSE=0, whereas 
I don't see that same language for XSAVE, even though the XSAVE_BV field would 
still be (un)set for not-in-use components.


r~