https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96572

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Keywords|                            |missed-optimization
   Last reconfirmed|                            |2020-08-25
             Status|UNCONFIRMED                 |NEW
                 CC|                            |msebor at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So phiprop sees

  <bb 2> [local count: 1073741824]:
  if (cond_4(D) != 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 3>; [50.00%]

  <bb 3> [local count: 536870913]:

  <bb 4> [local count: 1073741824]:
  # q_3 = PHI <&i(2), p_5(D)(3)>
  _1 = *q_3;
  _2 = *p_5(D);
  _7 = _1 + _2;
  i ={v} {CLOBBER};
  return _7;

and if we extend it to handle the case of a single address PHI operand
then we possibly would optimize this.  After PRE we then have

  <bb 2> [local count: 1073741824]:
  pretmp_9 = *p_5(D);
  if (cond_3(D) != 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 3>; [50.00%]

  <bb 3> [local count: 536870912]:

  <bb 4> [local count: 1073741824]:
  # q_2 = PHI <i_7(D)(2), pretmp_9(3)>
  _8 = q_2 + pretmp_9;
  return _8;

but then we're missing the optimistic copy propagation / value-numbering
we do not perform because it defeats uninit warnings.

So I'm not sure it is desirable to optimize this given the obvious
fallout this will cause for diagnostics.

After-phiprop proposed IL testcase we fail to optimize because of this:

int f(int *p, _Bool cond)
{
  int i;
  int q;
  if (cond)
    q = i;
  else
    q = *p;
  return q + *p;
}

Reply via email to