Re: Target FUNCTION_{PRO,EPI}LOGUE question

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

Joern Rennecke wrote:-

> Well, we could use a mask in the preprocessor to chop off the extra bits.

But you can't use a mask to add them :-)

> Please be carefull not to kill compile-time performance with a structured
> programming djihad.

It's not a religious thing, it's a correctness and maintenance issue.
I'd like GCC to be able to cross-compile from any reasonable host to
any reasonable target.  We're currently a long way from that, and
integer arithmetic is a major stumbling block.

If implemented properly [1], I think it could be faster than the
current implementation and get rid of the endless silly bugs we have
in the current code - see today's PR c/4363 - yet another signed /
unsigned integer precision issue.  They seem to be endless.

Neil.

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

But I could have this all wrong; it's just the way I see things at
present. [In fact, I wish our "tree" were fundamentally little more
than a vtable pointer, with no common data, just data specific to
whatever type it represents].