On Wed, Jun 4, 2008 at 16:03, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> However this was not the point of my mail. The point of my mail was whopr's > design that seems to basically sacrifice almost all interprocedural analysis > and transformation except for inlining in order to scale so as to be able to > compile programs of such size that most of the gcc community (including the > distros) will never see. There is absolutely nothing in WHOPR's design that sacrifices IPA transformations. I have tried to explain this several times, but I seem to have failed. I will try one more time. Suppose that you have a program with a callgraph in the million node range and no way to hold it in memory. With the current design, you either can't run IPA because of memory/computing limitations or you can start loading and unloading function bodies, types, symbols on-demand as you go in and out of each node in the callgraph. WHOPR simply adds another alternative, if you are willing to only run summary-based transformations, we can split the analysis and transformation phases in two such that you can parallelize the work over a cluster or a large SMP. That's it. Nothing more. All the other transformations may still be executed, nothing in the design prohibits this. If the program is small enough to fit on one machine, WHOPR simply runs the way LTO operates today. The only case where that can't happen is when you committed to spreading this out over a cluster. > I only want to raise the point that whopr is > at one end of a spectrum in which REAL tradeoffs are being made in the > quality of compilation vs size of program handled and there there is a real > possibility that being able to handle an entire program with these tradeoffs > is going to yield the fastest program or a reasonable compilation time. How is this detrimental to the rest of LTO? Your point seems moot. We are simply adding a new feature on top of the basic LTO machinery that we are also helping to build. I still don't see what you find so objectionable about this. Diego.
