This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Am Mon, 2002-12-30 um 00.45 schrieb Michael S.Zick:
> Daniel, have you considered that the "16 used registers" observation
> could be an artifact?
Yes.
> Presume an arbitrarily sophisticated optimization algorithum working
> on a symbolic machine with an infinite number of registers...
> Wouldn't the "16 used registers" observation fail as the size of the
> source file approached infinite size?
Depends on the code. Numerical applications tend to need far more
temporary values then say a notepad.
> Similarly with the size and complexity of a single expression statement.
> Those things are usually limited in size and complexity to what the
> human mind can comprehend.
The problem here is that you can surely recursivly inline the full
application into the main function, compile it as one chunk and then
be happy about the maximum use of registers; however at the same time
you absolutely blew code reuse and performancy because of cache abuse.
The effects you'll see describe exactly the troubles people have
determining ideal inlining limits. And without lots of inlining having
really a lot of registers will only benefit very specialised
applications which are unfortunately often "handoptimized" for a
particular processor and as such no good subject to compiler
optimisation.
And yes: I've actually tried what you mentioned with several larger
applications like The GIMP (with a modified paint core to force more
inlining) and there was no big increase in register usage, however I
have no figures about it since I really didn't care about this
particular number at that point.
I really think the whole idea is sound for register starved
architectures like i386 but don't expect too much from "unlimited"
registers because this is what we virtually have now with the current
optimisers.
BTW: Is there a good way to figure out how much registers the compiler
could have used sensibly if they were available? It's easy to count the
numbers of virtual registers allocated after the optimisation passes
but this number does not account for intersecting behaviour when
registers have to be saved and restored to make room for a different
content.
--
Servus,
Daniel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |