On Tue, Jun 3, 2008 at 22:26, Chris Lattner <[EMAIL PROTECTED]> wrote:
> and whopr here. Is LTO the mode "normal people" will use, and whopr is the > mode where "people with huge clusters" will use? Will LTO/whopr support > useful optimization on common multicore machines? As Ollie said, WHOPR is just an extension on the LTO framework to cater for scalability when building large applications. As such, when building large applications we expect not to be able to apply IPA passes that rely on having the whole program callgraph and bodies loaded in memory. However, WHOPR does not limit IPA passes to summary-only. That's why you see the distinction between IPA_PASS and SIMPLE_IPA_PASS in the pass manager. > Are you focusing on inlining here as a specific example, or is this the only > planned IPA optimization that can use summaries? It seems unfortunate to No. Just the first pass that we are going to concentrate for the initial implementation. >> == Design Philosophy == >> * The implementation provides complete transparency. Developers >> should be able to take advantage of LTO without having to modify >> existing build systems and/or Makefiles, all that's needed is to add >> an LTO option (-flto). > > Ok. How do you handle merging of optimization info? If I build one .o > file with -Os and one with -O3 who wins or what does this mean? If I build > one with -ffast-math and one without, does the right thing happen? Right now, mixed optimization flags will likely cause trouble. We have not really talked about this issue in detail. I expect many/most of these issues will be orthogonal to the driver, though. We've talked a bit about different ways of encoding the options into the IR, but there is nothing concrete yet. It's in my list of things to discuss at the next BoF. > Also, where does debug info (i.e. DWARF for -g) get stored? I'm not talking > about people debugging the compiler, I'm talking about people who want to > build an executable with debug info. In the .o file. We are generating regular .o files (for now). > Is there a specific reason you don't use the LLVM LTO interface? It seems > to be roughly the same as your proposed interface: Not really. This is mostly the first iteration. Rafael and Robert will be able to tell you much more about this. I'm not directly working on this aspect. Diego.
