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:

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

What we do now - at least in fold-const.c - is an existing fixed-width
multiple-precision representation, not a trivial reduction to host
operations.  This could be replaced by the general multiple precision
system.

While GMP has more than is needed, it should cover languages that need
general multiple precision, such as GNU Ada (though I don't know if the
multiple precision implementation in GNU Ada is part of the runtime
library; if so, this wouldn't work, since GMP is overkill for the runtime
library, though parts of it are actually used internally by GNU libc), and
has the great advantage that it is already written, optimised and
debugged.  G95 is already using GMP.

If this gets implemented, I think the initial implementation would best
just use GMP, and if this imposes much of a performance penalty then
alternatives can be added once the basic work has been done to make the
rest of GCC independent of the representation.  (At present, many places
depend on the structure of an INTEGER_CST.)

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

At least, you add a vtable pointer to the size of the integer, then.

I'm supposing that the integer representation - representing a signed
integer, with no specified type - is independent of C language rules for
unsigned arithmetic, overflow, interactions of different types, etc..  An
INTEGER_CST would then contain such an integer, together with type
information; and front ends would use the type, and general integer
functions (such a multiplying two unsigned integers modulo a given power
of 2), to implement the language-specific arithmetic rules.

It would be possible to optimise by having multiple representations - only
using general multiple precision for large integers - provide you avoid
introducing extra bugs, and work out the interactions when several
integers with different representations are used in one arithmetic
operation.

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

At present, an INTEGER_CST is allocated and garbage collected - but a
HOST_WIDE_INT, or an array of them, isn't.  Since all target integers
would now be in a format whose internals aren't exposed, they will all
need allocating/garbage collecting - slightly more complexity in order to
provide clean interfaces.

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