Feelings on macros vs inline in arch/$(ARCH)/syscall_arch.h ?

Feelings on macros vs inline in arch/$(ARCH)/syscall_arch.h ?

[Rich Felker]

In the process of optimizing mips and arm inline syscalls, it's come
to my attention that it could be beneficial for the inline syscall asm
to know that the syscall number is a constant. At present, due to our
use of inline functions rather than macros for inline syscalls, the
syscall number is never a "constant expression", and thus not suitable
for expansion as an immediate in inline asm.

What are the prevailing feelings on possibly changing this?

Using inline functions is nicer from standpoint of clean, more
standards-like (albeing __asm__-using) C code, and perhaps also helps
with debugging at -O0 where you can really see the call (as opposed to
a hideous inline macro expansion)

Using macros (which would necessitate GNU C "statement-expression"
hacks to get the return value) makes it possible to utilize the fact
that the syscall number is a constant, which could improve code
generation especially on mips and i386/PIC. The improvements would
mainly be in the areas of size and optimizing the surrounding code;
userspace code performance is all but irrelevant to the syscall
itself.

Rich

Re: Feelings on macros vs inline in arch/$(ARCH)/syscall_arch.h ?

[Arvid E. Picciani]

On Sun, 9 Sep 2012 14:23:44 -0400, Rich Felker wrote:

> Using inline functions is nicer from standpoint of clean [..]
>
> Using macros [..]  could improve code generation especially on mips 
> and i386/PIC.

I use musl because i can read it. For anything performance relevant we 
get customized bionic/gnulibc from vendors.

If i may, i suggest restricting performance optimizations at the cost 
of readability to areas that actually have a measurable effect for 
someone.


-- 
Arvid E. Picciani

Re: Feelings on macros vs inline in arch/$(ARCH)/syscall_arch.h ?

[Rich Felker]

On Wed, Sep 12, 2012 at 06:21:15PM +0200, Arvid E. Picciani wrote:
> On Sun, 9 Sep 2012 14:23:44 -0400, Rich Felker wrote:
> 
> >Using inline functions is nicer from standpoint of clean [..]
> >
> >Using macros [..]  could improve code generation especially on
> >mips and i386/PIC.
> 
> I use musl because i can read it. For anything performance relevant
> we get customized bionic/gnulibc from vendors.

That's an understandable position, but there are plenty of reasons to
want to use musl when performance does matter, for example in systems
where both performance and robustness matter. I don't claim everything
is complete and bug-free in musl right now, but there are significant
areas where musl has major reliability advantages over glibc already,
especially in things related to threads and cancellation.

> If i may, i suggest restricting performance optimizations at the
> cost of readability to areas that actually have a measurable effect
> for someone.

I don't think it affects code readability at all since it's tucked
away behind macros in the syscall headers already anyway. It more
affects debugging.

Anyway, I already solved the problem in a way that doesn't need
uglification, so no need to worry. Thanks for the input though.

Rich