div_qr_1 interface

[Torbjorn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  nisse at 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