Author: Eugene Nalimov
Date: 12:09:54 10/26/05
Go up one level in this thread
On October 26, 2005 at 07:44:13, Gerd Isenberg wrote:
>On October 25, 2005 at 17:12:58, Gian-Carlo Pascutto wrote:
>
>>On October 25, 2005 at 15:03:22, Gerd Isenberg wrote:
>>
>>>What other benefit has link-time code generation?
>>
>>Optimization across source files.
>>
>>--
>>GCP
>
>Yes, i had something similar in mind.
>But what concrete optimization could that be?
>
>Function prototypes, external data, classes or interfaces are in shared
>headerfiles anyway. Considering code of a set of source files is combined in one
>_TEXT segment anyway - so there is no need to have far calls/jumps.
>
>Is it like merging associated source files together to a huge one,
>allowing a kind of inlining across source files?
>
>Oh yes, i found something:
>http://msdn.microsoft.com/msdnmag/issues/02/05/Hood/
>
>Gerd
Problem is not only inlining. With LTCG compiler can much better alias analysis,
especially if you are using global variables -- e.g. consider the following
example:
int j;
void foo (int *p, int n)
{
int i;
for (i=0; i<n; i++)
p[i] = j;
}
Without LTCG we will re-load global variable "j" after each memory store, as
there is some chance that somebody will call function passing "&j" as first
argument and one as second. With LTCG we know that cannot happen because "j" is
non-address-taken variable -- we may still don't know where first argument of
foo() points, but we know it never points to "j". As a result we may enregister
global variable for the duration of loop.
Example is oversimplified but I believe you can see the point.
Another example: when compiling LTCG compiler knows all call sites of
non-address-taken functions. As a result we may analyze all call sites, and find
out if user is always passing the same constant as one of the arguments. In this
case we may replace all occurencies of the argument inside the function by the
constant -- and do that for large functions as well, when inlining would cause
unacceptable code growth. Such opportunities often happen when you are using
some general purpose library in your program.
There are more optimizations that benefit from LTCG, all of them using the
simple fact: with LTCG we can be sure that we are seeing all definitions and
uses of something in the program, so we can do optimizations that are generally
illegal, but are legal in that particular case. Examples are: non-standard
calling conventions on some platforms, called function register use analysis,
range analysis of the arguments we are passing to functions, alias analysis,
alignment analysis, etc.
You can achieve something similar combining all the C and header files into one
huge file and declaring everything "static", so that compiler knows that there
cannot be outside uses, but it's hard to do when your source code is shared
between several projects. In addition that approach becomes ugly and/or results
in slow compilations when you are developing -- you need fast edit/compile/link
turnaround cycle, and it's hard to do when you have 100k lines of sources. With
LTCG you don't have to recompile all your code for debug build when you modified
only one file.
Plus, it's much easier for customer to add one compiler flag to the compiler
command line than to re-structure complex makefile that is 15 years old. I've
seen 100k+ lines makefiles that people are rightly afraid to touch; nobody in
his/her mind will ever do something drastic with that file to speed up
application by 5%, while they may consider modifying one line to achieve the
same modest speedup.
Thanks,
Eugene
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.