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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
So we could have DSE ignore the padding bytes at the read point.  We may have
even discussed that at some point.  That results in something like this from
the gimple optimizers:

slow ()
{
  struct C D.25898;
  struct C D.29462;

;;   basic block 2, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;    prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;    pred:       ENTRY [always]  count:1073741824 (estimated locally)
(FALLTHRU,EXECUTABLE)
  MEM <char[4]> [(struct C *)&D.25898 + 8B] = {};
  D.25898.a = {};
  D.29462 = D.25898;
  D.25898 ={v} {CLOBBER};
  return D.29462;
;;    succ:       EXIT [always]  count:1073741824 (estimated locally)

}


But that still doesn't really help.  Even if we tell DSE stores to the bytes
for C.b aren't live (they're uninitialized), then we get something like this:

slow ()
{
  struct C D.25898;
  struct C D.29462;

;;   basic block 2, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;    prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;    pred:       ENTRY [always]  count:1073741824 (estimated locally)
(FALLTHRU,EXECUTABLE)
  D.25898.a = {};
  D.29462 = D.25898;
  D.25898 ={v} {CLOBBER};
  return D.29462;
;;    succ:       EXIT [always]  count:1073741824 (estimated locally)

}

WHich still isn't sufficient to get good code.

I'm not really sure what you want DSE to do here Richi :-)

Reply via email to