Missing qualifications

Chris Jefferson caj@cs.york.ac.uk
Thu Mar 10 14:26:00 GMT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


|
| Hummm, I'm not sure to understand: definitely inlining __find_if(...,
| random_access_iterator_tag), it's not an option, too big. The other one,
| it's ok to inline, and it's already marked as such. Or you mean *the
| latter* it's not inlined *always*, as it should (in order to also deal
| with the problem with zeroing)? In that case, we could play a bit with
| attribute always inline, perhaps. But, in general, I'm not sure to
| really understand what you mean by "instantiate to zero"... In the
| assembly of __ops::equal, before the eventual function call, is
| memory/registers zeroed?!?

I'll try to be more clear :)

Consider the following code, with no inlining
struct X { };
void foo(X,X,X) { };

void call_foo()
{ foo(X(),X(),X()); }

Looking at the assembler output for this code, g++ appears to insist on
making all classes at least 1 byte big, and also insists on
instansiating this one byte to zero (I think thats whats happening
anyway, I'll admit I'm not 100% sure). This is already a problem, for
when we add random_access_iterator_tag() and such like, and a very minor
problem (one more "assign zero"). But it's there.

While this is adding a very small regression, it's already a problem. We
tend to have lots of code like:

void library_function(...)
{ internal_function(...); }

At the moment what happens is the very tiny library_function gets
inlined into the user's code, so the user is "effectively" calling
internal_function. However often it will have an extra dummy parameter
or two. We need to either:

a) stop any (or as little as possible) code being generated for dummy
parameters or

b) force internal_function to be inlined into library_function, and have
user code just call library_function (or inline the whole lot)

I think (b) might be more sensible (the reason we can't just trust the
default inlining is we know that these quite large functions are only
used in one place), except I have no idea how it would intermingle with
the inlining heuristic.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCMFfb3FpDzErifpIRAiJBAJ4sLkzRCeS7C/WAKAUbf4wMt7vonACfffXT
Jb+MwwKglHl6V+8Y2m7GFr8=
=4q3E
-----END PGP SIGNATURE-----



More information about the Libstdc++ mailing list