Amd64 and va_arg | Hacker News Reader

Amd64 and va_arg

blog.nelhage.com

46 pointsSplines16 comments

Wow. Gross. On x86-64, caller args hit callee functions via registers, not the stack like they do on i386. This is a performance win. But functions like printf that take variable numbers of arguments need to go through contortions, saving copies of register arguments and painstakingly calculating which args would be on the stack versus registers (and their offset into the register save area) to work the same way on x86-64 than i386.

shrug va_args has to be written once, and once you get it right, the performance penalty should be much smaller than a memory access.

Also note that Power based architectures have been doing this for a long time.

Seems like the right trade-off to make. Variadic functions are so rarely used in performance-critical code that a couple of extra hoops for making printf and company work is probably worth it

It sounds like structs (at least the small ones?) get passed in registers also. I don't really understand that. Isn't it kinda a rule of C-programming that if you want your code to be fast, don't pass around structs? If structs just always went onto the stack, you wouldn't have to mess around figuring out whether its members are on the integer or floating point registers.

What's the performance sensitivity of variadic functions? I've never seen a varargs function hit the top of my profile. On i386, there's almost no performance difference between a va_arg and a positional arg.

It's actually not a rule of performant C programming that you shouldn't pass structures by value. The contortions you end up going through to avoid it (decomposing the struct into arguments, creating temp structs to pass addresses instead of values, filling structs in from return-args) often cost more than just passing the damn thing to begin with.

Yeah, my point was it's OK to make variadic functions have a little extra logic and in some cases potentially be slower than the ix86 equivalent, because regular functions are definitely sped-up and those are much more common.

On the subject of passing structs by value: it really comes down to whether you plan on copying the struct anyway or not, doesn't it?

I wonder if this is more for the sake of C++ than C, where primitive values are more likely to be 'boxed' into a struct/class along with some methods. For instance, with a typical non-debug standard library, vector<int>::iterator has one member - an int*. It'd be a shame if that couldn't go in a register.

I'm fairly sure that as soon as it's no longer POD (plain old data), it can no longer be passed in a register, though, as it MUST have a permanent memory address. A struct or class loses its POD-ness by having constructors, a destructor, being a derived class, having virtual functions, public/protected/private sections or a bunch of other very strict conditions. Simple iterators may well be POD in many STL implementations, though.

The Linux kernel, for example, uses the following definitions for page-table entries in different levels of amd64's four-level page tables:

    typedef struct { unsigned long pte; } pte_t;
    typedef struct { unsigned long pmd; } pmd_t;
    typedef struct { unsigned long pud; } pud_t;
    typedef struct { unsigned long pgd; } pgd_t;

That way, even though they're all represented as 64-bit values, the compiler will catch you if you try to mix-and-match different types without doing appropriate work.

Passing small structs in registers means that Linux can do that, and pass around `pte_t`s as parameters, without having to worry about paying a runtime cost for their typechecking.

That's a neat trick. Thanks for pointing that out.

This is a nice demonstration that C is actually (moderately) strongly typed - it's just that the keyword that introduces a new type is "struct", not "typedef".

I think that the MIPS does this quite well. There exist four (of 32) registers to hold the first four arguments to a function, and then any more go on the stack. However, most calling conventions require that you leave enough space in the stack frame to copy the argument registers into it (although you do not actually need to do the copy). That way, you can get the speed benefits of register-passed arguments while making it easy to do array indexing off the stack pointer if you really need to.

SPARC (V8 at least) is the same, just with 6 instead of 4 argument registers: %i0 to %i5.

I think SPARC has always had register argument passing; it's practically the design thesis for the processor.

It's not that arguments are passed in registers that makes it so complicated, but the fact that there are separate register files for integer/pointer and floating-point types. Most classic RISC architectures have only one register file.

I've never heard of variadic functions not being declared cdecl (_cdecl, __cdecl, whatever). This is also the first time I've ever heard that "C requires that code be able to call functions even if their prototype is not visible, which means the compiler doesn’t necessarily know if it’s calling a variadic function at any given call site." Can someone point to an authoritative reference for this?

On Win32 (and presumably most other systems as well) it's perfectly kosher to require variadic functions to be declared cdecl. This all sounds like a giant nonissue to me. Add support for cdecl functions and move on.

The comment about C requiring functions to be able to be called without a prototype in scope is not true, in the case of variadic functions. Calling a variadic function without a correct prototype in scope is undefined behaviour - so it's open to an ABI to specify a different calling convention for them.

(The relevant part of C99 is §6.5.2.2 Function Calls, p6).

Reply on news.ycombinator.com