[Bug target/79709] Subobtimal code with -mavx and explicit vector

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #2)
> We have trouble with your VSET macro (known issue):
>   two_28 = BIT_INSERT_EXPR <two_27(D), 2.0e+0, 0 (64 bits)>;
>   two_29 = BIT_INSERT_EXPR <two_28, 2.0e+0, 64 (64 bits)>;
>   two_30 = BIT_INSERT_EXPR <two_29, 2.0e+0, 128 (64 bits)>;
>   two_31 = BIT_INSERT_EXPR <two_30, 2.0e+0, 192 (64 bits)>;
> it is easier for gcc if you write:
>   v4do two={2,2,2,2};
> or you could even replace two with 2 in the expressions, gcc handles it just
> fine.

This part is not at all central to this PR, but we are really missing
optimizations on the new BIT_INSERT_EXPR.

typedef long vec __attribute__((vector_size(16)));
vec f(){
  long l;
  vec v={l,l};
  v[0]=0;
  v[1]=0;
  return v;
}

  _1 = {l_2(D), l_2(D)};
  v_4 = BIT_INSERT_EXPR <_1, 0, 0 (64 bits)>;
  v_5 = BIT_INSERT_EXPR <v_4, 0, 64 (64 bits)>;

so gcc could replace {l,l} with {0,l} after the first bit_insert_expr (_1 has a
single use), and then {0,0} after the second, one element at a time, the easy
case (though constructors are always tricky).