Torbjörn Granlund tg at
Wed Jun 24 09:49:10 UTC 2015

bodrato at 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: . 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

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.)

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list