Public mpn_add_nc

[Torbjorn Granlund]

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

  > I didn't list __gmpn_add_n_sub_n as public since I consider it
  > experimental.  It seemed like a good idea, but I never managed to make
  > it faster, not even for the large operands for which is was intended.
  
  I see. Main intended use was Schönhage-Strassen fft, or?
  
That's why it was added.

(We long ago discussed adding a full mpn_ss_butterfly [or whatever to
call it] which might be a better idea.  This is another discussion,
though.)

  > While __gmpn_add_nc makes more sense as public, I didn't suggest it to
  > be that for more practical reasons.  Many asm implementations do not
  > provide this entry point.
  >
  > I am not against making it public, but it cannot be done without
  > additional work.
  
  I see. I hope adding the entry points should be easy.
  
Shouldn't be too hard.

I'd suggest to:

* Rewrite the C functions to accept carry-in, and of course rename to _nc.

* Provide macros (or inlines) for mpn_add_n (mpn_sub_n)

* Provide fall-back mpn_add_n (mpn_sub_n) for the library (needed for
  link compatibility, these functions have long been public).  These
  fallbacks could just call _nc, or ave the current code.

* Conditionally provide  _nc for when asm procides _n.

This is some hours of work to get it all right, and test it.
Until somebody fixes it, we just keep _nc non-public.

-- 
Torbjörn