RFC: Should x86-64 support arbitrary calling conventions?

Richard Henderson rth@twiddle.net
Mon Mar 27 05:36:00 GMT 2017


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.


r~



More information about the Libc-alpha mailing list