[Bug target/93737] inline memmove for insertion into small arrays

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---
Confirmed.

[Bug target/93737] inline memmove for insertion into small arrays

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
On GIMPLE we're more into canonicalization which means we avoid this kind of
expansion and thus at the moment limit it to single load/store cases.  But
in principle we could apply the same costing as we later do during RTL
expansion (note a memcpy/memmove is easier to handle for VN / alias-analysis
than decomposed operation).

Note memmove can be generally expanded inline if you perform all loads
before the first store at the expense of requiring a temporary register
for each load.

[Bug target/93737] inline memmove for insertion into small arrays

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I was thinking for small N, the middle-end could make it work by emitting
copies of the sequences using MEM_REFs, along these lines:

  char _2[N - 2];
  _2 = MEM  [(char * {ref-all}) + 1];
  MEM  [(char * {ref-all}) + 2] = _2;

[Bug target/93737] inline memmove for insertion into small arrays

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Sdee the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01618.html
Continued at:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00277.html

This infastructure patch was committed October 2, 2019.  So it is now a target
specific issue.