On Tue, 2005-11-22 at 13:21 -0600, Benjamin Kosnik wrote: > > Okay, but you need to understand that reasonable bounds for compiling > > the entire program at once are usually 3x-7x more (and in the worst > > case, even wore) than doing it seperately. > > > > That is the case with completely state of the art algorithms, > > implementation techniques, etc. > > > > It's just the way the world goes. > > > > It's in no way reasonable to expect to be able to perform IPA > > optimizations on a 1 million line program in 30 seconds, even if we can > > compile it normally in 10 seconds. > > Tree-SSA managed to add new technology to the compiler without major > slowdowns. I'm suggesting that whatever LTO technology is used do > the same for non-LTO programs. I consider this reasonable.
This is fine. > > Now, I think you are setting the compile time performance bar for LTO > awfully low. I'm not asking for new funtionality to be as fast as the > current technology without the functionality (although that would > certainly be nice, wouldn't it?). > > Certainly, icc with IPO is definitely not as slow as you claim. I'm done arguing any of these points (yours, Richard's about debug info, or anyone else's). For once, I'm simply going to sit on the sidelines for 2 years while everyone else does (or does not) do something about the problems we face moving to IPA. So let me just say, as a final analysis: 1. Richard, LLVM carries debug info in the exact same way we would do so in GVM (transmitting it in the IL), and keeping it up to date in the optimizers would also have to be done the same way. When Chris says "LLVM doesn't support debug info" he means it does not *produce* any debug info. if you compile a file with llvm-gcc -g, you will see familiar line tracking information, function start/end info, and lexical region info, and compile units. The thing missing is to write out the dwarf2 info we've accumulated, into the approriate global llvm compile unit descriptors, and then pass that along the same exact way we do in tree-ssa land. We do almost nothing to truly keep it up to date in the tree optimizers, except for a very small number of passes, and this would also be true of LLVM. 2. Ben, I'm not sure where you think icc with IPO is fast. It takes 15 minutes to IPA compile xemacs on my machine with icc, and 230 meg of memory. non-ipa it takes 3 minutes and 60 meg of memory. You are *lucky* to have only a 5x slowdown when you have any large amount of code. I've done a lot of work in IPA, not just on GCC. You are really in for a surprise if you think that compiling an industrial application isn't going to take literally days with IPA optimizations when it takes hours without it. Again, it's fine to say the non-LTO programs should compile fast. But I am setting the LTO compile time goal to what i believe it can meet. I still think it would be a mistake to redo all of this from scratch than start with something else, because i think we, as usual, vastly underestimate the amount of work our data structures will need. I eagerly await someone to make gcc --combine not take 2 gigabytes of memory to compile gcc, but still optimize it very well and have reasonable compile time bounds By the by, to compile something like libsablevm (after removing the 6 lines of inline assembly), gcc takes >120 meg of memory (in fact, 4.0 takes 260 meg of memory), and 35 seconds (at O2 or O3, your choice). This is just tree optimizer time i'm including. llvm-gcc takes only 64 meg of memory, and 32 seconds, while performing a whole bunch of of interprocedural optimizations to boot. But again, i'm just going to sit on the sidelines from now on and let someone else come up with all the technical solutions and work. I'm truly not a proponent of either proposal (though it may seem that way), but nobody has given any more details about how they plan on changing anything so it's memory and compile time efficient in the other one, only how to write it out and read it back in. We've been saying we'd solve these issues since *I* started working on gcc, but we still get our ass handed to us by everyone else on things like memory usage. --Dan
