[Bug target/90424] memcpy into vector builtin not optimized

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-05-13
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot 
gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ick, C++ ... so I see for example

load<char, 8> (const void * p)
{
  W r;
  long unsigned int _3;
  V _5;

  <bb 2> [local count: 1073741824]:
  _3 = MEM[(char * {ref-all})p_2(D)];
  MEM[(char * {ref-all})&r] = _3;
  _5 = r;
  r ={v} {CLOBBER};
  return _5;

but it's not clear to me whether W is a vector type and whether r could
be re-written into SSA form or not.

Good one(?)

load<long int, 8> (const void * p)
{
  W r;
  long unsigned int _3;
  long int _4;

  <bb 2> [local count: 1073741824]:
  _3 = MEM[(char * {ref-all})p_2(D)];
  _4 = (long int) _3;
  r_6 = BIT_INSERT_EXPR <r_5(D), _4, 0 (64 bits)>;
  return r_6;


note that bit-inserting into a default-def probably isn't the best thing
to do, but well.

Another variant:

load<double, 8> (const void * p)
{
  W r;
  long unsigned int _3;
  double _4;

  <bb 2> [local count: 1073741824]:
  _3 = MEM[(char * {ref-all})p_2(D)];
  _4 = VIEW_CONVERT_EXPR<double>(_3);
  r_6 = BIT_INSERT_EXPR <r_5(D), _4, 0 (64 bits)>;
  return r_6;

so the bad variants are where we retain the aggregate copy.

So for the first case above we have

 <var_decl 0x7ffff7fefc60 r
    type <vector_type 0x7ffff69e9348 W
        type <integer_type 0x7ffff68983f0 char public string-flag type_6 QI
            size <integer_cst 0x7ffff687af18 constant 8>
            unit-size <integer_cst 0x7ffff687af30 constant 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff68983f0 precision:8 min <integer_cst 0x7ffff687af60 -128> max
<integer_cst 0x7ffff687af90 127>
            pointer_to_this <pointer_type 0x7ffff69e9690>>
        sizes-gimplified V16QI
        size <integer_cst 0x7ffff687ae70 constant 128>
        unit-size <integer_cst 0x7ffff687ae88 constant 16>
        align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff69a0b28 nunits:16
        pointer_to_this <pointer_type 0x7ffff69e93f0>>
    addressable used tree_1 read decl_1 decl_5 V16QI t.ii:7:5 size <integer_cst
0x7ffff687ae70 128> unit-size <integer_cst 0x7ffff687ae88 16>
    align:128 warn_if_not_align:0 context <function_decl 0x7ffff69d6500 load>>

but then we fail to rewrite this into SSA because the

  MEM[(char * {ref-all})&r] = _3;

assign is a partial assign of a 'long' value into a vector<char> vector.
Currently BIT_INSERT_EXPR is restricted to insertion of vector type
components so we'd have to apply a series of VIEW_CONVERT_EXPRs to 'r'
to insert _3 or alternatively allow upper/lower halves, like inserting
v4qi into v16qi at position 0, 4, 8 or 12, where we then only would
have to VIEW_CONVERT _3.

Note in the end it will matter what targets implement, otherwise you'll
get spilling if we have to go through memory for the insertion.

I will look into changing SSA rewrite in one or other way.