ni...@lysator.liu.se (Niels Möller) writes: ni...@lysator.liu.se (Niels Möller) writes: (about using a small struct as return value) > If the caller is going to store the returned value directly in memory > anyway, there's little difference. And if the caller is going to operate > on the return value, and needs it in a register, I think struct return > should be epsilon more efficient. Things are different on 32-bit x86; there the struct seems to be returned via a pointer passed by the caller (on the stack, like all arguments). So the crude measure of the number of instructions for the example divrem function grows from 13 to 18 when using a struct return value. I think you might be mistaken. Perhaps you're using a structure of two long long fields?
This example, struct retme { unsigned long int a, b; }; struct retme foo (struct retme x) { struct retme y; y.a = x.a + 17; y.b = x.b + 4711; return y; } is compiled by gcc 4.7.2 into, movl 8(%esp), %edx addl $4711, %edx movl 4(%esp), %eax addl $17, %eax ret indicating that (like any argument) the struct is passed on the stack, but it is returned in a register pair. How much do we care about 32-bit x86 these days? What other ABIs out there can't return a small (two word-sized elements) struct in registers? I think x86-64, x86-32, arm32, arm64, powerpc-64, sparc-64 matter. Unfortunately, powerpc-64 (and -32) return these types onto the stack via an implicit pointer. I think all the other listed get it right. (I was involved in the powerpc-64 ELF ABI; I will slap my fingers...) In principle, since these are internal functions, I guess one could use struct {mp_limb_t r, mp_limb_t qh } mpn_div_qr_1n_pi1 (...) on some systems and mp_limb_t mpn_div_qr_1n_pi1 (..., mp_limb_t *qhp) on others, depending on which style is most efficient. But that seems messy. That's conceivable, and perhaps one could reduce the pain by using sone clever macros. -- Torbjörn _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel