| |||||||||||||
whole-program optimisation the hard waywhole-program optimisation the hard wayPosted May 18, 2006 8:16 UTC (Thu) by job (guest, #670)In reply to: whole-program optimisation the hard way by massimiliano Parent article: Some patches of interest
I think the poltics nix refers to is that if gcc writes down intermediate representations to disk you suddenly have a perfect opportunity to extend gcc with non-free software. One of the reasons gcc has been the most successful free compiler is that new architectures and optimizers has to go in via free code, if you had the ability to swap out the back end that would not have happened.
(Log in to post comments)
whole-program optimisation the hard way Posted Jul 16, 2006 7:55 UTC (Sun) by jzbiciak (✭ supporter ✭, #5246) [Link] One easy way to address that is to generate the specific encoding when you build the compiler. That is, if the output of GCC really is the binary representation of GCC's internal representation, it will be *very* dependent on the specific version of GCC you're using.
Thus, it won't be a stable interface. Not even close.
I think it's perfectly acceptable to require a complete rebuild if the compiler version changes on you and you're trying to do whole-program optimization. Sure, it makes the feature harder to use, but it doesn't constrain it unnecessarily.
The fact of the matter is that unless the IR is merely the GIMPLE output of the front end, different versions of the compiler are going to have different things to say about the code within the IR it outputs. And if the IR is merely just the GIMPLE output from the front end, well, you've only saved parsing time across all your source files. Every build -fwhole-program runs everything else on the entire program. You only start saving build time noticeably if you output stuff from later stages of analysis.
|
|||||||||||||