speed488
speed488

Reputation: 306

GCC 4.6.3 Linux -O3 enabled optimizations listing vs applied to code disparity. Is the order of optimization affecting the code compilation?

I'm facing a problem with GCC 4.6.3 which I can't find any logic solution/explanation. I'm working on a project of porting an embedded firmware application with OS to a Linux based application. The application has a whole bunch of unit tests that can be activated via arguments to check the sanity of the code/features.

When I compile in debug, everything works 100% and all unit tests pass. However, I had issues with release build (with -O3 optimizations). I managed to isolate the problematic file. The file comes from a external package not codded by us and we do not want to change it at all.

I took GCC's documentation to get all the optimizations included in -O3. Here is what I got:

-fauto-inc-dec
-fcprop-registers
-fdce
-fdefer-pop
-fdse
-fguess-branch-probability
-fif-conversion2
-fif-conversion
-finline-small-functions
-fipa-pure-const
-fipa-reference
-fmerge-constants
-fsplit-wide-types
-ftree-builtin-call-dce
-ftree-ccp
-ftree-ch
-ftree-copyrename
-ftree-dce
-ftree-dominator-opts
-ftree-dse
-ftree-fre
-ftree-sra
-ftree-ter
-funit-at-a-time
-fomit-frame-pointer
-fthread-jumps
-falign-functions
-falign-jumps
-falign-loops
-falign-labels
-fcaller-saves
-fcrossjumping
-fcse-follow-jumps
-fcse-skip-blocks
-fdelete-null-pointer-checks
-fexpensive-optimizations
-fgcse
-fgcse-lm
-findirect-inlining
-foptimize-sibling-calls
-fpeephole2
-fregmove
-freorder-blocks
-freorder-functions
-frerun-cse-after-loop
-fsched-interblock
-fsched-spec
-fschedule-insns
-fschedule-insns2
-fstrict-aliasing
-fstrict-overflow
-ftree-switch-conversion
-ftree-pre
-ftree-vrp
-finline-functions
-funswitch-loops
-fpredictive-commoning
-fgcse-after-reload
-ftree-vectorize
-fipa-cp-clone

I found out that it was -fschedule-insns that was causing the problem. Removing this optimization got the code working fine again.

Here is what I can't explain, GCC's documentation says that if you want to know exactly what is GCC applying, you can write this in the console gcc -Q -O3 --help=optimizers | grep "enabled". I did and here is the output:

-falign-functions                   [enabled]
-falign-jumps                       [enabled]
-falign-labels                      [enabled]
-falign-loops                       [enabled]
-fasynchronous-unwind-tables        [enabled]
-fbranch-count-reg                  [enabled]
-fcaller-saves                      [enabled]
-fcombine-stack-adjustments         [enabled]
-fcommon                            [enabled]
-fcompare-elim                      [enabled]
-fcprop-registers                   [enabled]
-fcrossjumping                      [enabled]
-fcse-follow-jumps                  [enabled]
-fdce                               [enabled]
-fdefer-pop                         [enabled]
-fdelete-null-pointer-checks        [enabled]
-fdevirtualize                      [enabled]
-fdse                               [enabled]
-fearly-inlining                    [enabled]
-fexpensive-optimizations           [enabled]
-fforward-propagate                 [enabled]
-fgcse                              [enabled]
-fgcse-after-reload                 [enabled]
-fgcse-lm                           [enabled]
-fguess-branch-probability          [enabled]
-fif-conversion                     [enabled]
-fif-conversion2                    [enabled]
-finline-functions                  [enabled]
-finline-functions-called-once      [enabled]
-finline-small-functions            [enabled]
-fipa-cp                            [enabled]
-fipa-cp-clone                      [enabled]
-fipa-profile                       [enabled]
-fipa-pure-const                    [enabled]
-fipa-reference                     [enabled]
-fipa-sra                           [enabled]
-fivopts                            [enabled]
-fjump-tables                       [enabled]
-fmath-errno                        [enabled]
-fmerge-constants                   [enabled]
-fmove-loop-invariants              [enabled]
-foptimize-register-move            [enabled]
-foptimize-sibling-calls            [enabled]
-fpeephole                          [enabled]
-fpeephole2                         [enabled]
-fpredictive-commoning              [enabled]
-fprefetch-loop-arrays              [enabled]
-fregmove                           [enabled]
-frename-registers                  [enabled]
-freorder-blocks                    [enabled]
-freorder-functions                 [enabled]
-frerun-cse-after-loop              [enabled]
-frtti                              [enabled]
-fsched-critical-path-heuristic     [enabled]
-fsched-dep-count-heuristic         [enabled]
-fsched-group-heuristic             [enabled]
-fsched-interblock                  [enabled]
-fsched-last-insn-heuristic         [enabled]
-fsched-rank-heuristic              [enabled]
-fsched-spec                        [enabled]
-fsched-spec-insn-heuristic         [enabled]
-fsched-stalled-insns-dep           [enabled]
-fschedule-insns2                   [enabled]
-fshort-enums                       [enabled]
-fsigned-zeros                      [enabled]
-fsplit-ivs-in-unroller             [enabled]
-fsplit-wide-types                  [enabled]
-fstrict-aliasing                   [enabled]
-fthread-jumps                      [enabled]
-fno-threadsafe-statics             [enabled]
-ftoplevel-reorder                  [enabled]
-ftrapping-math                     [enabled]
-ftree-bit-ccp                      [enabled]
-ftree-builtin-call-dce             [enabled]
-ftree-ccp                          [enabled]
-ftree-ch                           [enabled]
-ftree-copy-prop                    [enabled]
-ftree-copyrename                   [enabled]
-ftree-cselim                       [enabled]
-ftree-dce                          [enabled]
-ftree-dominator-opts               [enabled]
-ftree-dse                          [enabled]
-ftree-forwprop                     [enabled]
-ftree-fre                          [enabled]
-ftree-loop-distribute-patterns     [enabled]
-ftree-loop-if-convert              [enabled]
-ftree-loop-im                      [enabled]
-ftree-loop-ivcanon                 [enabled]
-ftree-loop-optimize                [enabled]
-ftree-phiprop                      [enabled]
-ftree-pre                          [enabled]
-ftree-pta                          [enabled]
-ftree-reassoc                      [enabled]
-ftree-scev-cprop                   [enabled]
-ftree-sink                         [enabled]
-ftree-slp-vectorize                [enabled]
-ftree-sra                          [enabled]
-ftree-switch-conversion            [enabled]
-ftree-ter                          [enabled]
-ftree-vect-loop-version            [enabled]
-ftree-vectorize                    [enabled]
-ftree-vrp                          [enabled]
-funit-at-a-time                    [enabled]
-funswitch-loops                    [enabled]
-fvar-tracking                      [enabled]
-fvar-tracking-assignments          [enabled]
-fvect-cost-model                   [enabled]
-fweb                               [enabled]

-fschedule-insns is not in the list, it's marked as disabled if I remove the grep. If I take all the optimizations listed by GCC's command output and compile the problematic file with the supplied list, the code still passes. What is wrong here?

Here is a wrap-up. If I use -O3 directly, it fails. If I use all the optimizations of -O3 listed in GCC's documentation, it fails. If I used all the optimizations of -O3 provided by GCC from command line it passes. Finally, if I use all the optimizations of -O3 listed in GCC's documentation excluding -fschedule-insns, it passes.

What is the true optimization listing of -O3 !?! GCC's documentation or what GCC is telling via command line? I'm confused and out of ideas on how I can get a positive/logical explanation to this.

Anybody faced this kind of issue with GCC?

Upvotes: 5

Views: 808

Answers (1)

Iwillnotexist Idonotexist
Iwillnotexist Idonotexist

Reputation: 13457

Excellent question. You've just discovered that, as always, the source is the only truth. There is even a bug in GCC's Bugzilla for this.

I'll draw your attention to two places in the GCC source code.

  1. In gcc-4.6.3/gcc/opts.c, line 474, we see within the table of default options the following:

        { OPT_LEVELS_2_PLUS, OPT_frerun_cse_after_loop, NULL, 1 },
        { OPT_LEVELS_2_PLUS, OPT_fcaller_saves, NULL, 1 },
        { OPT_LEVELS_2_PLUS, OPT_fpeephole2, NULL, 1 },
    #ifdef INSN_SCHEDULING
      /* Only run the pre-regalloc scheduling pass if optimizing for speed.  */
        { OPT_LEVELS_2_PLUS_SPEED_ONLY, OPT_fschedule_insns, NULL, 1 },
        { OPT_LEVELS_2_PLUS, OPT_fschedule_insns2, NULL, 1 },
    #endif
        { OPT_LEVELS_2_PLUS, OPT_fregmove, NULL, 1 },
        { OPT_LEVELS_2_PLUS, OPT_fstrict_aliasing, NULL, 1 },
        { OPT_LEVELS_2_PLUS, OPT_fstrict_overflow, NULL, 1 },
        { OPT_LEVELS_2_PLUS, OPT_freorder_blocks, NULL, 1 },
    
  2. In gcc-4.6.3/gcc/config/i386/i386.c, line 5166, we see

    static const struct default_options ix86_option_optimization_table[] =
      {
        /* Turn off -fschedule-insns by default.  It tends to make the
           problem with not enough registers even worse.  */
    #ifdef INSN_SCHEDULING
        { OPT_LEVELS_ALL, OPT_fschedule_insns, NULL, 0 },
    #endif
    
    #ifdef SUBTARGET_OPTIMIZATION_OPTIONS
        SUBTARGET_OPTIMIZATION_OPTIONS,
    #endif
        { OPT_LEVELS_NONE, 0, NULL, 0 }
      };
    

We may draw the conclusion that the documentation is only partially correct; Some passes are actually disabled on some targets even at the O-level they'd normally be enabled at. In particular, the x86, mep and mcore-derived targets disable schedule-insns at all optimization levels by default, even though it is supposed to be enabled at -O2 and up. You can still force-enable it manually, but you run the risks for which it was disabled in the first place.

Also, -fschedule_insns may be disabled by default at all levels if the compiler was built with INSN_SCHEDULING disabled.

Upvotes: 4

Related Questions