https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341
--- Comment #8 from Fredrik Hederstierna <fredrik.hederstie...@securitas-direct.com> --- Could it be something in tree-ssa-forwprop pass? This pass is executed 4 times in -Os, and starting with GCC-4.9 it seems like statements that seems to generate instructions that are hard to eliminate later in compilation could be propagated? Checking 4.8.5 (good result) ;; Function test (test, funcdef_no=0, decl_uid=4075, cgraph_uid=0) test (struct table_s * table, int xi) { struct item_s * item; int _6; int _7; int _9; int _11; int _13; <bb 2>: item_4 = &table_2(D)->items[xi_3(D)]; _6 = item_4->type; switch (_6) <default: <L4>, case 1: <L0>, case 2: <L1>, case 3: <L2>, case 4: <L3>> <L0>: _7 = item_4->name; handle_case_1 (_7); goto <bb 7> (<L4>); <L1>: _9 = item_4->name; handle_case_2 (_9); goto <bb 7> (<L4>); <L2>: _11 = item_4->name; handle_case_3 (_11); goto <bb 7> (<L4>); <L3>: _13 = item_4->name; handle_case_4 (_13); <L4>: return; } ------------------- Same code GCC 4.9.3 (bad result) ;; Function test (test, funcdef_no=0, decl_uid=4090, symbol_order=0) test (struct table_s * table, int xi) { struct item_s * item; int _6; int _7; int _9; int _11; int _13; <bb 2>: _6 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].type; switch (_6) <default: <L4>, case 1: <L0>, case 2: <L1>, case 3: <L2>, case 4: <L3>> <L0>: _7 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name; handle_case_1 (_7); goto <bb 7> (<L4>); <L1>: _9 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name; handle_case_2 (_9); goto <bb 7> (<L4>); <L2>: _11 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name; handle_case_3 (_11); goto <bb 7> (<L4>); <L3>: _13 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name; handle_case_4 (_13); <L4>: return; } When comparing the two versions of "tree-ssa-forwprop.c" it seems like sometimes there are removed checks for invariant code, eg. in forward_propagate_addr_expr_1() there are no checks for is_gimple_min_invariant(), but I'm not familiar with this code is it might just fine, it was just an observation, since it seems like invariant code are propagated here, but maybe I'm wrong. When compiling for speed there is less downside in copying statements, its like loop unrolling or peeling, but when optimizing for size its always bad if later passes cannot eliminate these extra copied instructions again I think. Maybe propagation should be more restrictive when optimizing for size? I did not see any checks for optimization type in forwardpropagation, but maybe its intended to only do zero-cost propagations? Thank & BR/Fredrik