Re: [PATCH][RFC] Add -Og
On Sep 4, 2012, at 22:42 , Hans-Peter Nilsson h...@bitrange.com wrote: Please, no inlining. Think of stack back-traces and their use when debugging. But, there was a talk at the GNU Tools Cauldron with related contents - http://gcc.gnu.org/wiki/cauldron2012#Control-flow_preservation_in_GCC_for_safety-critical_uses. It'll be Very Nice if control flow preservation was part of -Og or at least they played nice together. A general comment first: I think the compromise Richard aims at satisfying is a very useful one: It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. While there are commonalities with preserve-control-flow, indeed, there are differences in target concerns as well. We did a lot of work to support inlining for example :-) Our experience is that compromises of this kind are extremely sensitive to micro details spreadout in multiple places, so I'm afraid having one part of the other might be hard. Olivier
Re: [PATCH][RFC] Add -Og
On 4 September 2012 21:42, Hans-Peter Nilsson h...@bitrange.com wrote: On Mon, 3 Sep 2012, Richard Guenther wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). Please, no inlining. Think of stack back-traces and their use when debugging. I would argue [without sufficient knowledge of how easy this would actually be to do in a real compiler :-)] that this is a debugger problem and not a compiler issue. With DWARF as the debug info format it should certainly be possible to produce a view that looked like: $ bt #0b baz (...) #0a inlined into bar (...) #0 inlined into foo (...) #1 do_something #2 main This would involve reading the .debug_frame, and then looking up the inlined subroutines via .debug_info. I personally would like as much optimisation as possible at -Og that doesn't break a defined level of debug illusion. I have seen too many cases where people debug at -O0/-O1 and then build a release with a -O2/-O3 build and get bitten by undefined behaviour issues. The more optimised -Og code is the less the reason to release a build at a higher optimisation level. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org
Re: [PATCH][RFC] Add -Og
On Wed, Sep 5, 2012 at 10:46 AM, Matthew Gretton-Dann matthew.gretton-d...@linaro.org wrote: Please, no inlining. Think of stack back-traces and their use when debugging. I would argue [without sufficient knowledge of how easy this would actually be to do in a real compiler :-)] that this is a debugger problem and not a compiler issue. It's also a compiler issue if you take inlining of clones into account, or scheduling such that the inlined body is scattered all over in the the caller's body. The compiler can tell the debugger only so much... Ciao! Steven
Re: [PATCH][RFC] Add -Og
On 5 September 2012 09:55, Steven Bosscher stevenb@gmail.com wrote: On Wed, Sep 5, 2012 at 10:46 AM, Matthew Gretton-Dann matthew.gretton-d...@linaro.org wrote: Please, no inlining. Think of stack back-traces and their use when debugging. I would argue [without sufficient knowledge of how easy this would actually be to do in a real compiler :-)] that this is a debugger problem and not a compiler issue. It's also a compiler issue if you take inlining of clones into account, or scheduling such that the inlined body is scattered all over in the the caller's body. The compiler can tell the debugger only so much... But that's not a problem with inlining, that's a problem with allowing things to happen out of order (for some definition of things and order) - which in my understanding -Og is going to tie down. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org
Re: [PATCH][RFC] Add -Og
On Wed, 5 Sep 2012, Matthew Gretton-Dann wrote: On 5 September 2012 09:55, Steven Bosscher stevenb@gmail.com wrote: On Wed, Sep 5, 2012 at 10:46 AM, Matthew Gretton-Dann matthew.gretton-d...@linaro.org wrote: Please, no inlining. Think of stack back-traces and their use when debugging. I would argue [without sufficient knowledge of how easy this would actually be to do in a real compiler :-)] that this is a debugger problem and not a compiler issue. It's also a compiler issue if you take inlining of clones into account, or scheduling such that the inlined body is scattered all over in the the caller's body. The compiler can tell the debugger only so much... But that's not a problem with inlining, that's a problem with allowing things to happen out of order (for some definition of things and order) - which in my understanding -Og is going to tie down. Yes, the goal is definitely to avoid the jumping back and forth on source lines you can see when debugging optimized programs. Btw, the patch only lies the foundation for all the goals that accumulated in this thread to be eventually fulfilled. I only tried to collect the minimal set of optimizations that do not automatically defeat any of them ;) Any comments on the implementation details btw? Thanks, Richard.
Re: [PATCH][RFC] Add -Og
On Wed, Sep 05, 2012 at 11:07:17AM +0200, Richard Guenther wrote: But that's not a problem with inlining, that's a problem with allowing things to happen out of order (for some definition of things and order) - which in my understanding -Og is going to tie down. Yes, the goal is definitely to avoid the jumping back and forth on source lines you can see when debugging optimized programs. Btw, the patch only lies the foundation for all the goals that accumulated in this thread to be eventually fulfilled. I only tried to collect the minimal set of optimizations that do not automatically defeat any of them ;) The jumping back and forth could be fixed by limiting scheduling only to insns with the same locus with -Og or something similar (if doing scheduling at all). Of course the fewer gimple passes that reorder stmts the better too. Guess some inlining ought to be allowed, but e.g. IPA cloning should be definitely disabled. Jakub
Re: [PATCH][RFC] Add -Og
On Sep 5, 2012, Richard Guenther rguent...@suse.de wrote: Yes, the goal is definitely to avoid the jumping back and forth on source lines you can see when debugging optimized programs. Hmm... If that's the goal, how about adding to the mix the Statement Frontier Notes proposal I advanced in some GCC Summit? Its goal is precisely to mark user-relevant viewpoints for a debugger to stop so as at to get a consistent and progressive view of the computation. Sure enough, there are optimizations that don't make much room for that, and so it would make sense for -Og to disable those, to get excellent results, rather than just -gO0d ones ;-) Any comments on the implementation details btw? Not really, sorry. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [PATCH][RFC] Add -Og
On Mon, 3 Sep 2012, H.J. Lu wrote: On Mon, Sep 3, 2012 at 11:50 AM, rguent...@suse.de wrote: H.J. Lu hjl.to...@gmail.com wrote: On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. When I debug binutils, I have to use -O0 -g to get precise line and variable info. Also glibc has to be compiled with -O, which makes debug a challenge. Will -Og help bintils and glibc debug? I suppose so, but it is hard to tell without knowing more about the issues. The main issues are 1. I need to know precise values for all local variables at all times. That would certainly be a good design goal for -Og (but surely the first cut at it won't do it). 2. Compiler shouldn't inline a function or move lines around. Let's split that. 2. Compiler shouldn't inline a function well - we need to inline always_inline functions. And I am positively sure people want trivial C++ abstraction penalty to be removed even with -Og, thus getter/setter methods inlined. Let's say the compiler should not inline a function not declared inline and the compiler should not inline a function if that would increase code size even if it is declared inline? 3. Compiler shouldn't move lines around. A good goal as well, probably RTL pieces are least ready for this. 4. Generated code should be small and fast, compile-time and memory usage should be low. Unless either of it defeats 1. to 3. The patch only provides a starting point and from the GIMPLE side should be reasonably close to the goals above. Richard.
Re: [PATCH][RFC] Add -Og
On 04/09/12 10:45, Richard Guenther wrote: On Mon, 3 Sep 2012, H.J. Lu wrote: On Mon, Sep 3, 2012 at 11:50 AM, rguent...@suse.de wrote: H.J. Lu hjl.to...@gmail.com wrote: On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. When I debug binutils, I have to use -O0 -g to get precise line and variable info. Also glibc has to be compiled with -O, which makes debug a challenge. Will -Og help bintils and glibc debug? I suppose so, but it is hard to tell without knowing more about the issues. The main issues are 1. I need to know precise values for all local variables at all times. That would certainly be a good design goal for -Og (but surely the first cut at it won't do it). 2. Compiler shouldn't inline a function or move lines around. Let's split that. 2. Compiler shouldn't inline a function well - we need to inline always_inline functions. And I am positively sure people want trivial C++ abstraction penalty to be removed even with -Og, thus getter/setter methods inlined. Let's say the compiler should not inline a function not declared inline and the compiler should not inline a function if that would increase code size even if it is declared inline? 3. Compiler shouldn't move lines around. A good goal as well, probably RTL pieces are least ready for this. 4. Generated code should be small and fast, compile-time and memory usage should be low. Unless either of it defeats 1. to 3. The patch only provides a starting point and from the GIMPLE side should be reasonably close to the goals above. Richard. I'd add 5. User variables don't have to live in memory (or in any single place), but there should only be one 'live' location at any one time. Changing the value of a variable at a sequence point/statement/line boundary (pick a definition and document it) should affect all subsequent uses of that variable. Values assigned to variables remain available until the declaration goes out of scope. R.
Re: [PATCH][RFC] Add -Og
On 4 September 2012 10:45, Richard Guenther rguent...@suse.de wrote: On Mon, 3 Sep 2012, H.J. Lu wrote: On Mon, Sep 3, 2012 at 11:50 AM, rguent...@suse.de wrote: H.J. Lu hjl.to...@gmail.com wrote: On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. When I debug binutils, I have to use -O0 -g to get precise line and variable info. Also glibc has to be compiled with -O, which makes debug a challenge. Will -Og help bintils and glibc debug? I suppose so, but it is hard to tell without knowing more about the issues. The main issues are 1. I need to know precise values for all local variables at all times. That would certainly be a good design goal for -Og (but surely the first cut at it won't do it). 2. Compiler shouldn't inline a function or move lines around. Let's split that. 2. Compiler shouldn't inline a function well - we need to inline always_inline functions. And I am positively sure people want trivial C++ abstraction penalty to be removed even with -Og, thus getter/setter methods inlined. Let's say the compiler should not inline a function not declared inline and the compiler should not inline a function if that would increase code size even if it is declared inline? I don't see a problem with inlining functions under -Og - under a couple of assumptions: * The debug table format can correctly mark inlined functions (DWARF can - I don't know about other formats). * The compiler is executing sequence points in order - and so the function being inlined doesn't 'spill out' into the function it is inlined into. See below for further comments. This should provide enough information to the debugger to allow it to maintain the illusion that an inlined function is a separate function, and enable a user to set breakpoints on all calls to the function. 3. Compiler shouldn't move lines around. A good goal as well, probably RTL pieces are least ready for this. I would change this to say something like (using C language terms): The compiler should provide enough information to allow breakpoints to be set at each sequence point, and that the state of the machine is such that everything before that sequence point will have been completed and that nothing after that sequence point will have been started. It is probably also possible to argue that there is a case for having points between sequence points where we say the code would be in a good state (lets call them observation points). So for instance we might want to say that in: int x, a, b, c; ... x = a + b * c; If we just say we only promise a known state at sequence points then the compiler is free to use some form of multiply-accumulate instruction here. But a user may want to see the multiply followed by addition split out. So we could define the observation points to be on the *, +, and =. 4. Generated code should be small and fast, compile-time and memory usage should be low. Unless either of it defeats 1. to 3. The patch only provides a starting point and from the GIMPLE side should be reasonably close to the goals above. Richard. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org
Re: [PATCH][RFC] Add -Og
On Tue, Sep 4, 2012 at 4:16 AM, Matthew Gretton-Dann matthew.gretton-d...@linaro.org wrote: On 4 September 2012 10:45, Richard Guenther rguent...@suse.de wrote: On Mon, 3 Sep 2012, H.J. Lu wrote: On Mon, Sep 3, 2012 at 11:50 AM, rguent...@suse.de wrote: H.J. Lu hjl.to...@gmail.com wrote: On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. When I debug binutils, I have to use -O0 -g to get precise line and variable info. Also glibc has to be compiled with -O, which makes debug a challenge. Will -Og help bintils and glibc debug? I suppose so, but it is hard to tell without knowing more about the issues. The main issues are 1. I need to know precise values for all local variables at all times. That would certainly be a good design goal for -Og (but surely the first cut at it won't do it). It will be harder to use it to debug binutils. 2. Compiler shouldn't inline a function or move lines around. Let's split that. 2. Compiler shouldn't inline a function well - we need to inline always_inline functions. And I am positively sure people want trivial C++ abstraction penalty to be removed even with -Og, thus getter/setter methods inlined. Let's say the compiler should not inline a function not declared inline and the compiler should not inline a function if that would increase code size even if it is declared inline? I don't see a problem with inlining functions under -Og - under a couple of assumptions: * The debug table format can correctly mark inlined functions (DWARF can - I don't know about other formats). * The compiler is executing sequence points in order - and so the function being inlined doesn't 'spill out' into the function it is inlined into. See below for further comments. This should provide enough information to the debugger to allow it to maintain the illusion that an inlined function is a separate function, and enable a user to set breakpoints on all calls to the function. It works for me. 3. Compiler shouldn't move lines around. A good goal as well, probably RTL pieces are least ready for this. I would change this to say something like (using C language terms): The compiler should provide enough information to allow breakpoints to be set at each sequence point, and that the state of the machine is such that everything before that sequence point will have been completed and that nothing after that sequence point will have been started. It is probably also possible to argue that there is a case for having points between sequence points where we say the code would be in a good state (lets call them observation points). So for instance we might want to say that in: int x, a, b, c; ... x = a + b * c; If we just say we only promise a known state at sequence points then the compiler is free to use some form of multiply-accumulate instruction here. But a user may want to see the multiply followed by addition split out. So we could define the observation points to be on the *, +, and =. The problem I run into is next in gdb can go backward within the same function when compiled with optimization. It makes harder for me to use breakpoints to track where/when the problem happens. -- H.J.
Re: [PATCH][RFC] Add -Og
On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. Richard. Thanks, Richard. 2012-08-10 Richard Guenther rguent...@suse.de PR other/53316 * common.opt (optimize_debug): New variable. (Og): New optimization level. * doc/invoke.texi (Og): Document. * opts.c (maybe_default_option): Add debug parameter. (maybe_default_options): Likewise. (default_options_optimization): Handle -Og. (common_handle_option): Likewise. * passes.c (gate_all_optimizations): Do not run with -Og. (gate_all_optimizations_g): New gate, run with -Og. (pass_all_optimizations_g): New container pass, run with -Og. (init_optimization_passes): Schedule pass_all_optimizations_g alongside pass_all_optimizations. * gcc/testsuite/lib/c-torture.exp: Add -Og -g to default TORTURE_OPTIONS. Index: trunk/gcc/common.opt === *** trunk.orig/gcc/common.opt 2012-07-19 10:39:47.0 +0200 --- trunk/gcc/common.opt2012-08-10 11:58:22.218122816 +0200 *** int optimize *** 32,37 --- 32,40 Variable int optimize_size + Variable + int optimize_debug + ; Not used directly to control optimizations, only to save -Ofast ; setting for optimize attributes. Variable *** Ofast *** 446,451 --- 449,458 Common Optimization Optimize for speed disregarding exact standards compliance + Og + Common Optimization + Optimize for debugging experience rather than speed or size + Q Driver Index: trunk/gcc/opts.c === *** trunk.orig/gcc/opts.c 2012-07-24 10:35:57.0 +0200 --- trunk/gcc/opts.c2012-08-10 12:48:38.986018411 +0200 *** init_options_struct (struct gcc_options *** 314,328 } /* If indicated by the optimization level LEVEL (-Os if SIZE is set, !-Ofast if FAST is set), apply the option DEFAULT_OPT to OPTS and !OPTS_SET, diagnostic context DC, location LOC, with language mask !LANG_MASK and option handlers HANDLERS. */ static void maybe_default_option (struct gcc_options *opts, struct gcc_options *opts_set, const struct default_options *default_opt, ! int level, bool size, bool fast, unsigned int lang_mask, const struct cl_option_handlers *handlers, location_t loc, --- 314,328 } /* If indicated by the optimization level LEVEL (-Os if SIZE is set, !-Ofast if FAST is set, -Og if DEBUG is set), apply the option DEFAULT_OPT !to OPTS and OPTS_SET, diagnostic context DC, location LOC, with language !mask LANG_MASK and option handlers HANDLERS. */ static void maybe_default_option (struct gcc_options *opts, struct gcc_options *opts_set, const struct default_options *default_opt, ! int level, bool size, bool fast, bool debug, unsigned int lang_mask, const struct cl_option_handlers *handlers, location_t loc, *** maybe_default_option (struct gcc_options *** 335,340 --- 335,342
Re: [PATCH][RFC] Add -Og
Richard Guenther richard.guent...@gmail.com writes: Comments welcome, No comments? Then I'll drop this idea for 4.8. FWIW I liked the idea. But I'm not really competent to review the implementation. On x86 I would enable frame pointers. Even though gdb doesn't need them, some other profiling and debugging tools do. Also I would add a bootstrap-Og build config to make it easier to test for bootstrap (or maybe change the existing bootstrap-debug?) -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [PATCH][RFC] Add -Og
Hi, On Mon, 3 Sep 2012, Richard Guenther wrote: Comments welcome, No comments? Then I'll drop this idea for 4.8. Hey, don't discard my face2face comments :) Regarding -Og it's about time, I like it, and your implementation is a start. The pass list (e.g. if to include LIM or not, or in a limited form) can be incrementally changed. Ciao, Michael.
Re: [PATCH][RFC] Add -Og
On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. When I debug binutils, I have to use -O0 -g to get precise line and variable info. Also glibc has to be compiled with -O, which makes debug a challenge. Will -Og help bintils and glibc debug? H.J.
Re: [PATCH][RFC] Add -Og
H.J. Lu hjl.to...@gmail.com wrote: On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. When I debug binutils, I have to use -O0 -g to get precise line and variable info. Also glibc has to be compiled with -O, which makes debug a challenge. Will -Og help bintils and glibc debug? I suppose so, but it is hard to tell without knowing more about the issues. Richard. H.J. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [PATCH][RFC] Add -Og
On Mon, Sep 3, 2012 at 11:50 AM, rguent...@suse.de wrote: H.J. Lu hjl.to...@gmail.com wrote: On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther rguent...@suse.de wrote: This adds a new optimization level, -Og, as previously discussed. It aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Instead of making -O1 this optimization level this adds a new -Og. It's a first cut, highlighting that our fixed pass pipeline and simply enabling/disabling individual passes (but not pass copies for example) doesn't scale to properly differentiate between -Og and -O[23]. -O1 should get similar treatment, eventually just building on -Og but not focusing on debugging experience. That is, I expect that in the end we will at least have two post-IPA optimization pipelines. It also means that you cannot enable PRE or VRP with -Og at the moment because these passes are not anywhere scheduled (similar to the situation with -O0). It has some funny effect on dump-file naming of the pass copies though, which hints at that the current setup is too static. For that reason the new queue comes after the old, to not confuse too many testcases. It also does not yet disable any of the early optimizations that make debugging harder (SRA comes to my mind here, as does switch-conversion and partial inlining). The question arises if we want to support in any reasonable way using profile-feedback or LTO for -O[01g], thus if we rather want to delay some of the early opts to after IPA optimizations. Not bootstrapped or fully tested, but it works for the compile torture. Comments welcome, No comments? Then I'll drop this idea for 4.8. When I debug binutils, I have to use -O0 -g to get precise line and variable info. Also glibc has to be compiled with -O, which makes debug a challenge. Will -Og help bintils and glibc debug? I suppose so, but it is hard to tell without knowing more about the issues. The main issues are 1. I need to know precise values for all local variables at all times. 2. Compiler shouldn't inline a function or move lines around. -- H.J.
