Re: RFC: Should x86-64 support arbitrary calling conventions?

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Mar 26, 2017 at 10:36 PM, Richard Henderson <rth@twiddle.net> wrote:
> On 03/24/2017 07:31 PM, Florian Weimer wrote:
>>
>> * H. J. Lu:
>>
>>> I compared time for "make check" in glibc.  On Nehalem and Skylake,
>>> the time differences are within noises.  On Knights Landing, xsave
>>> is about 1% slower.
>>
>>
>> Thanks for doing this benchmarking.
>>
>> What's the increase in stack usage?
>>
>>> I don't expect xsave will make any differences for long running
>>> benchmarks.  Its impact may only show up on short programs which
>>> call external functions a few times with lazy binding.
>>>
>>> Should we consider it at all?
>>
>>
>> I think the main benefit is that we don't have to adjust the dynamic
>> linker trampoline for each new microarchitecture, and applications can
>> safely start using new CPU features once the kernel indicates support.
>
>
> Not quite true, at least as written.  The STATE_SAVE_MASK define selects
> which components get saved.  This would have to be changed for additional
> cpu bits that could be modified.
>
> One *could* set EAX:EDX = -1 and store everything, and then, yes, we'd be
> done with changes to glibc for all cpu changes.
>

For relevant CPU features, they probably need kernel support.  It should
be trivial to update STATE_SAVE_MASK when adding kernel support.


-- 
H.J.