This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about the highly optimized aspects of libc implementation


On 30 November 2017 at 12:17, Will Hawkins <whh8b@virginia.edu> wrote:
> Please let me apologize at the start if this is the wrong venue to ask
> this question.

This is the perfect venue for these questions.

> I've been digging through the glibc implementation and looking for
> examples of where compiler directives or hand-written assembly have
> been used to improve performance at the "expense" of standards or
> conventions.
>
> I know that question seems incredibly vague but I'm struggling to put
> it into better terms. I am not necessarily looking for places where
> certain functions have been highly optimized (ie, the *cpy functions
> for x86) -- I can find those relatively easily in the sysdeps.
>
> Maybe an example will help?
>
> Are there cases where function _a_ calls function _b_ without adhering
> to the normal calling convention or the platform ABI because the
> implementer knows that only function _a_ will call function _b_ and
> knows which registers are dead/preserved/etc?

Here's a couple that I know off the top of my head:

There are some ASM implementations that assume that overwriting callee
saved registers is safe without saving them because it *knows* that
the caller doesn't use them.  Some pthread functions in x86/x86_64
were examples of these but a number of them were dropped in the recent
past so I don't know if that still is a case.

A lot of the internal function calls in i686 use registers to pass
arguments instead of the standard ABI that mandates using the stack.

Siddhesh
-- 
http://siddhesh.in


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]