ni...@lysator.liu.se (Niels Möller) writes:
t...@gmplib.org writes:
Not sure why we're doing this as an inline function in gmp.h.
Me neither. Perhaps as it is tiny?
I think inlines in gmp.h makes sense for functions which are tiny and
O(1) in the common case, like
t...@gmplib.org writes:
Not sure why we're doing this as an inline function in gmp.h.
Me neither. Perhaps as it is tiny?
I think inlines in gmp.h makes sense for functions which are tiny and
O(1) in the common case, like mpn_add_1 and mpn_cmp. Or small O(1)
wrappers around O(n)
bodr...@mail.dm.unipi.it writes:
mpn_neg id defined in gmp.h, where we can not check for HAVE_NATIVE, but I
suspect that also the C version of mpn_com is faster than mpn_neg (in the
former, limbs do not depend on one another, no carry propagation).
I'd suggest something like this (totally
On 2015-04-29 07:01:39 +0200, bodr...@mail.dm.unipi.it wrote:
diff -r 6e11cd70e19e gmp-h.in
--- a/gmp-h.inMon Apr 27 22:46:53 2015 +0200
+++ b/gmp-h.inTue Apr 28 22:41:52 2015 +0200
@@ -2191,13 +2191,10 @@
mp_limb_t
mpn_neg (mp_ptr __gmp_rp, mp_srcptr __gmp_up, mp_size_t
ni...@lysator.liu.se (Niels Möller) writes:
I'd suggest something like this (totally untested)
mp_limb_t
mpn_neg (mp_ptr rp, mp_srcptr up, mp_size_t n)
{
/* Low zero limbs are unchanged by negation. */
while (*up == 0)
{
*rp++ = 0;
up++;
I just noticed that the fast mpn_com in x86_64/fastsse is not really
used, making calls to mpn_com from the inlined mpn_neg perform poorly.
I'll address this soon.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
