This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PR 18143] thunk range
Gabriel Dos Reis wrote:
Jakub Jelinek <jakub@redhat.com> writes:
| On Mon, Nov 01, 2004 at 10:14:45AM +0000, Nathan Sidwell wrote:
| > PR 18143 is about a problem with the newly restricted thunk range.
| >
| > Option 1 is to revert the restriction.
| > Option 2 is to add a sorry.
| >
| > Option 1 is unarguably to be preferred, if it has no down sides.
| > Unfortunately it does. Reverting the patch makes lang_decl bigger, and
| > that impacts compile time -- by a surprising amount. I built
| > --disable-checking compilers on both powerpc-apple-darwin and
| > i686-pc-linux-gnu and then measured the -O0 compile time for QT. There
| > was a 1% slowdown on both platforms. This is bad.
|
| Speed is important, but not as important that we should add impose artificial
| limits on the users IMHO.
| So I'm for Option 1.
Strongly agree here. INSHMO.
I think I do as well, sad though I am to lose performance.
There are probably other tricks you could play here, though. For
example, you could number all your base objects, and then encode the
base object number there. That would allow you to recover the delta,
but presumably people would be less concerned about limiting the number
of base class objects to two million. (I know I would not be bothered
by such a restriction.) I suppose you could also index into a global
array of thunk offsets, and assume that you will never have more than
two million distinct thunk offsets -- also seems like a reasonable
assumption to me.
Perhaps best: you could have a thunk_lang_decl which is like a lang_decl
-- but with some extra space for the thunk offset. That would start us
towards static trees, and not penalize non-thunk functions.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com