bdiv vs redc

Torbjorn Granlund tg at gmplib.org
Thu Jun 28 14:26:51 CEST 2012


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

  > A comment says:
  >   /* FIXME: Add ASSERTs for allowable overlapping; i.e., that qp = np is OK,
  >      but some over N/Q overlaps will not work.  */
  > I think we changed this during last year.  Putting the quotient in that
  > place is a workaround for callers in the absence lf an _r function variant.
  >
  > Are we talking about different functions?
  
  I'm looking at mpn_sbpi1_bdiv_qr. I suspect that comment doesn't take
  the current implementation into account. The typical loop (for the case
  qn <= dn) uses these stores:
  
        np[i] = mpn_addmul_1 (np + i, dp, dn, q);
        qp[i] = ~q;
  
  If q were to be stored at the low end of the n input, np == qp, those
  two stores collide.
  
Maybe, but we talked about this and after the discussion I checked in a
change described like this:

2011-12-10  Torbjorn Granlund  <tege at gmplib.org>

	* mpn/generic/sbpi1_bdiv_q.c: Delay quotient limb stores in order to
	allow quotient and dividend to completely overlap.
	* mpn/generic/sbpi1_bdiv_qr.c: Likewise.

Perhaps it doesn't work, or does not always work (depending on relative
operand sizes).  I cannot remember what usage needed this change, it
might have been the new binomomial code.

  For redc, tradition mandates the low end. But maybe callers could
  accept the high end without additional overhead? That needs some
  investigation; if that can work out it will simplify things.
  
Agreed.

  High end seems more "natural" for this operation, and for the calls from
  within dc_bdiv and mu_bdiv, I would be surprised if using anything but
  the high end doesn't cause trouble. Using the low end as alien in the
  same way as having euclidean division place the remainder at the high
  end.
  
Don't exaggerate...!  And what is "natural" is less important what makes
things smooth, we're talking mpn after all!

-- 
Torbjörn


More information about the gmp-devel mailing list