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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic,
                   |                            |missed-optimization
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-04-15
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot 
gnu.org
   Target Milestone|---                         |5.2
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's (good)

  <bb 2>:
  _4 = e_3(D)->pu;
  if (&x != _4)
    goto <bb 3>;
  else
    goto <bb 5>;

  <bb 5>:
  goto <bb 4>;

  <bb 3>:
  _5 = MEM[(char * {ref-all})_4];
  MEM[(char * {ref-all})&x] = _5;

  <bb 4>:
  _7 = x;
  x ={v} {CLOBBER};
  return _7;

vs. (bad)

  <bb 2>:
  _4 = e_3(D)->pu;
  if (&x != _4)
    goto <bb 4>;
  else
    goto <bb 3>;

  <bb 3>:
  pretmp_9 = x;
  goto <bb 5>;

  <bb 4>:
  _5 = MEM[(char * {ref-all})_4];

  <bb 5>:
  # prephitmp_10 = PHI <pretmp_9(3), _5(4)>
  x ={v} {CLOBBER};
  return prephitmp_10;

that's a missed PRE opportunity in the good case (not sure why we use
unsigned int for the memcpy inlining - ah, because it goes the new
single load/store case in gimple_fold_builtin_memory_op).  PRE should
still be able to handle.

Only after PRE we hit the very special case where uninit warns about memory
reads (no store before the reads).  For this case inconsistencies are
very much expected...

But the testcase also shows a missed optimization opportunity because
&x can never be equal to e->pu (PR13962).

Reply via email to