Re: Target FUNCTION_{PRO,EPI}LOGUE question

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Thu, 28 Jun 2001, Neil Booth wrote:

> [1] My idea would be that we abstract it through something similar to
> a tree, say a tree_int, that is little more than a vtable that amongst
> other things provides an array of function pointers to do operations
> like add, multiply etc, and contains a suitable target integer
> representation for the host.  Then at build time we could set up the
> vtable to the fast, trivial implementations if the host int sizes are
> the same as the target, and other, either multiple-precision or
> losing-precision, implementations if not.  This would probably be
> faster, and certainly much easier to read, than the way we handle this
> stuff at present.

I'm not sure that we can optimise to trivial implementations quite so 
simply, since we want e.g. overflow detection on signed arithmetic, ISO C 
makes overflow on signed arithmetic undefined, and GCC optimises some 
operations on the basis that signed overflow is undefined.

Using a multiple-precision library would replace a lot of existing
multiple-precision arithmetic in GCC, e.g. much of fold-const.c.  Some
obvious things that need working out first are:

* How much of the memory GCC uses, in trees and RTL, is used for storing
target integers?  Multiple-precision representations would use more memory 
than the existing fixed-width 2 x HOST_WIDE_INT, and I think this has more 
chance of being a problem than extra CPU time.

* What model is used for memory allocation of multiple-precision integers?
We might for example provide constructor functions, and use garbage
collection, to insulate most of the compiler from the details of how e.g.
GMP does things.

-- 
Joseph S. Myers
jsm28@cam.ac.uk