mpn_zero_p

[Torbjörn Granlund]

bodrato at mail.dm.unipi.it writes:

  In general, when supporting zero sizes is an O(1) cost compared to an O(n)
  or bigger cost of the function, I may agree.
  On average mpn_zero_p will return after the first branch (on random data,
  the first limb we check is non-zero). Supporting zero sizes here means
  doubling the branches on average...
  
That's the kind of reasoning I do, so I must agree with you.  :-)

  In the whole library, only two calls to mpn_zero_p required support for
  zero size: https://gmplib.org/repo/gmp/rev/cb5da779cc81 . The other will
  benefit of the reduced branching.
  
I didn't intend to question your change to mpn_zero_p.  I just wanted to
clarify my view on mpn and zero sizes in general; the manual text you
quoted is not a law by which I intend to abide.  :-)

  Sometimes we have oddities in the library.
  E.g. mpn_sqrtrem requires that "The most significant limb of {sp, n} must
  be non-zero.", but supports n=0 (not tested by our test-suite, look at
  https://gmplib.org/devel/lcov/shell/var/tmp/lcov/gmp/mpn/sqrtrem.c.gcov.html
  ).

That seems weird.

  mpn/x86_64/fastsse/com.asm does support zero size with an initial
          test    n, n
          jz      L(don)
  while neither the generic C function for the library ( mpn/generic/com.c ),
  nor the inlined version in gmp-impl.h does.
  
A mistake, clearly.

(I believe assembly code occasionally support zero sizes as a result of
their unrolling logic.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622