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

Reply via email to