gmp_pi1_t

[Niels Möller]

Joerg Arndt <arndt at jjj.de> writes:

> The 'inline' keyword is your friend.
> Inlined functions are optimized across their
> boundaries which is often more important than
> just avoiding call overhead.

Inline is used in some places in gmp. But I think most of the functions
that take a struct gmp_pi1_t * argument are too large to be usefully
inlined.

> The compiler should remove 'fall through' functions entirely.
> IIRC there is some optimization switch regarding this issue.

I'm not sure what you mean. In this case, the difference is between

  struct gmp_pi1_t { mp_limb_t inv32 } inv;
  foo (... &inv);

and

  mp_limb_t inv;
  foo (..., inv);

Last time I looked (which was several years ago), if you use the
address-of operator & on a local variable anywhere in a function, gcc
never ever allocates that variable in a register. So this is a small
performance penalty for the "abstracted" version of the code.

In principle, if foo is inlined, the compiler could maybe optimize away
the address-of operation. gcc probably does? But does it redo register
allocation at that point, so that the struct can be put in a register?

In gmp, we don't pass structs by value, and we don't return structs. I
imagine there are portability reasons for that, possibly historic. If we
would pass the struct above by value rather than by reference, then the
compiler should be able to optimize away everything related to the
struct container. But I don't think that's a good alternative in this
case, since the point of gmp_pi1_t is to make it possible to add various
other members without changing the interface, and I don't think we want
to pass large structs by value.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.