From: Kenneth Zadeck <zadeck@naturalbridge.com>
To: Ollie Wild <aaw@google.com>
Cc: Chris Lattner <clattner@apple.com>,
Diego Novillo <dnovillo@google.com>,
gcc@gcc.gnu.org, Jan Hubicka <jh@suse.cz>,
Rafael Espindola <espindola@google.com>,
Robert Hundt <rhundt@google.com>
Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA
Date: Wed, 04 Jun 2008 20:03:00 -0000 [thread overview]
Message-ID: <4846F50A.5050900@naturalbridge.com> (raw)
In-Reply-To: <65dd6fd50806041223l1871ecfbh384aa175c3da0645@mail.gmail.com>
Ollie Wild wrote:
> On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner <clattner@apple.com
> <mailto:clattner@apple.com>> wrote:
>
>
> 1) start with all code in memory and see how far you can get. It
> seems that on reasonable developer machines (e.g. 2GB memory) that
> we can handle C programs on the order of a million lines of code,
> or C++ code on the order of 400K lines of code without a problem
> with LLVM.
>
>
> This is essentially what the lto branch does today, and I don't see
> any reason to disable this feature. In the language of the WHOPR
> design, the lto branch supports LGEN + LTRANS, with WPA bypassed
> completely. For implementing WPA, my intention is to add a new flag
> (-fpartition or whatever else people think is suitable) to instruct
> the lto1 front end to perform partitioning (aka repackaging) of .o
> files, execute summary IPA analysese, and kick off a separate LTRANS
> phase.
This is what lto does today because this was the easiest thing to do to
be able to continue to develop and test the other parts of the
system. it is stupidly implemented - it required only five lines of
code (two of them being curly braces according to the gcc coding
standards) so it allowed us to work on other things.
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. I realize
that there is handwaving that sure, there is this or that could possibly
be implemented by someone else for programs of modest scale, but that is
not what whopr is all about.
I do not want to imply that google's needs are not real and that they
should not use gcc to fulfill them. 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.
kenny
next prev parent reply other threads:[~2008-06-04 20:03 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-03 16:46 Diego Novillo
2008-06-04 2:27 ` Chris Lattner
2008-06-04 7:28 ` Rafael Espindola
2008-06-04 16:34 ` Chris Lattner
2008-06-04 16:48 ` Rafael Espindola
2008-06-04 13:00 ` Diego Novillo
2008-06-04 15:28 ` Kenneth Zadeck
2008-06-04 15:54 ` Ian Lance Taylor
2008-06-04 16:50 ` Kenneth Zadeck
2008-06-04 17:05 ` Diego Novillo
2008-06-04 17:37 ` Ian Lance Taylor
2008-06-04 16:15 ` Chris Lattner
[not found] ` <65dd6fd50806041223l1871ecfbh384aa175c3da0645@mail.gmail.com>
2008-06-04 19:30 ` Fwd: " Ollie Wild
[not found] ` <89069638-6D2B-4AE6-ACB3-99A2B09091BA@apple.com>
2008-06-04 20:02 ` Ollie Wild
2008-06-04 23:59 ` Diego Novillo
2008-06-04 20:03 ` Kenneth Zadeck [this message]
2008-06-04 20:30 ` Ian Lance Taylor
2008-06-04 20:56 ` Diego Novillo
2008-06-05 15:10 ` Jan Hubicka
2008-06-05 15:23 ` Diego Novillo
2008-06-04 14:28 ` Ian Lance Taylor
2008-06-04 16:29 ` Chris Lattner
2008-06-04 16:41 ` Chris Lattner
2008-06-04 18:48 ` Devang Patel
2008-06-04 19:45 ` Ian Lance Taylor
2008-06-04 20:38 ` Nick Kledzik
2008-06-04 20:46 ` Ian Lance Taylor
2008-06-04 21:43 ` Nick Kledzik
2008-06-05 0:01 ` Ian Lance Taylor
2008-06-05 0:20 ` Nick Kledzik
2008-06-05 0:43 ` Ian Lance Taylor
2008-06-05 1:09 ` Nick Kledzik
2008-06-05 5:07 ` Devang Patel
2008-06-05 5:43 ` Ian Lance Taylor
2008-06-05 6:09 ` [whopr] plugin interface design Chris Lattner
2008-06-05 13:53 ` Ian Lance Taylor
2008-06-05 16:37 ` Chris Lattner
2008-06-05 17:39 ` Ian Lance Taylor
2008-06-07 18:31 ` Chris Lattner
2008-06-05 5:44 ` [whopr] Design/implementation alternatives for the driver and WPA Ian Lance Taylor
2008-06-05 8:41 ` Rafael Espindola
2008-06-05 14:00 ` Ian Lance Taylor
2008-06-05 16:44 ` Chris Lattner
2008-06-05 17:44 ` Ian Lance Taylor
2008-06-05 18:50 ` Nick Kledzik
2008-06-05 21:03 ` Ian Lance Taylor
2008-06-05 21:47 ` Chris Lattner
2008-06-06 1:22 ` Ian Lance Taylor
2008-06-07 18:34 ` Chris Lattner
[not found] ` <65dd6fd50806032310u2bda0953qb911e3ccfe3f305e@mail.gmail.com>
2008-06-04 19:29 ` Fwd: " Ollie Wild
2008-06-04 14:45 ` Ian Lance Taylor
2008-06-04 14:48 ` Diego Novillo
2008-06-04 15:28 ` Rafael Espindola
2008-06-04 16:31 ` Mark Mitchell
2008-07-04 3:31 ` Cary Coutant
2008-07-04 6:28 ` Ian Lance Taylor
2008-07-04 22:58 ` Daniel Jacobowitz
2008-07-06 7:30 ` Cary Coutant
2008-07-07 6:13 ` Ian Lance Taylor
2008-07-04 13:43 ` Rafael Espindola
2008-07-06 14:22 ` Cary Coutant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4846F50A.5050900@naturalbridge.com \
--to=zadeck@naturalbridge.com \
--cc=aaw@google.com \
--cc=clattner@apple.com \
--cc=dnovillo@google.com \
--cc=espindola@google.com \
--cc=gcc@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=rhundt@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).