Re: Target FUNCTION_{PRO,EPI}LOGUE question

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Joseph S. Myers wrote:-

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

I don't understand - why can't we do whatever we do now, but through
an indirect function call?  I'm sure that GMP, say, as-is is not what
we want, we'd have to change some things.  We probably only need a
subset of GMP.

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

I don't see why you need to use more memory to store the int than the
target size.  For same-size targets, you might even same memory on the
current scheme.  There's no need to stick to the current single-sized
representation for all target ints either - you could have target_int,
target_long etc. all different sizes.  The compiler has no need to
know which it's handling - behaviour is determined solely by what the
vtable points to.

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

I would imagine the same as we do now.  Why would the compiler need to
have any unnecessary stuff exposed? - that's what the vtable is for.

Neil.