Re: Target FUNCTION_{PRO,EPI}LOGUE question

[Fergus Henderson <fjh at cs dot mu dot oz dot au>]

On 28-Jun-2001, Joseph S. Myers <jsm28@cam.ac.uk> wrote:
> 
> I agree that we need a multiple precision arithmetic library
> for use for target arithmetic.  [...]  I tend to
> think we should just use GMP [...]  though Torbjorn
> Granlund thinks GMP is inappropriate for this
> <URL:http://gcc.gnu.org/ml/gcc/2000-11/msg00725.html>.

For GMP or any other arbitrary-precision integer arithmetic library,
you're going to pay the costs of dynamic allocation and/or (for
cases where the representation of small numbers is optimized)
the costs of dynamically checking which representation is being used.
So if N is small (e.g. 2), a fixed N-word representation may be cheaper.

I don't understand all the complications of cross-compiling gcc,
so I may be misunderstanding things and/or completely missing something.
But I don't see why we would need N>2 currently.
If the native compiler is only used for bootstrapping, then
we're guaranteed to have a 64 bit `long long' available when
building the cross-compiler, and two of those gives 128 bits.
Is there a need for >128 bits of precision?

Would doing the following steps be sufficient to solve the problem(s)?
- changing the preprocessor to use pairs of HOST_WIDE_INT
  (as is done in INTEGER_CST tree nodes)
  and to take the modulo w.r.t the target intmax_t size
  after each operation
- as in the current main branch, make "HOST_WIDE_INT" be "long long"
  when cross-compiling from 32-bit host to 64-bit target
- fixing the issue with COBOL requiring 128 bit precision even on
  32-bit hosts by making "HOST_WIDE_INT" also be "long long" when
  building the COBOL front-end (and changing the rules for
  `make bootstrap' so that it builds the COBOL front-end
  separately from the others, rebuilding libbackend.a)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.