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).
