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]

Re: An unusual Performance approach using Synthetic registers


On Sunday 29 December 2002 07:32 am, Daniel Egger wrote:
> Am Son, 2002-12-29 um 05.31 schrieb Andy Walker:
> > Color-graphing works better, the more registers there are available for
> > use. Six registers is sub-optimal.  Sixteen registers is a good start. 
> > Thirty-two plus five gives thirty-seven, enough for the algorithm to
> > excel.
>
> However if you have a look at register rich architectures like PPC
> you'll see that the generated code rarely exceeds a number of 16 used
> registers, most of them being used for parameters and return values.
> use of registers.
>
Daniel, have you considered that the "16 used registers" observation
could be an artifact?

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?

Consider now some of the current practices that limit the size of the
source that the compiler "sees" prior to final optimization and allocation
to actual registers...

Function in-lining is done within a source file.

The size of in-lined functions is limited.

Sources are broken into multiple files, the size of which is kept (hopefully)
down to what can be comprehended by the human mind.  Which can be
expected to be considerably less than the file size that a compiler can
"comprehend".

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.

For instance...
Pick a portion of the compiler (represented as a *.o file) that is actually
the combination of multiple *.o files seperately compiled.
Rather than seperately compile the sources of the component *.o files,
text edit them into one huge source file.
Remove limits on function in-lining.
Compile.
Examine.
Did the "16 used registers" observation hold?

Mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]