On Mon, Jan 15, 2018 at 6:20 PM, Will Schmidt <will_schm...@vnet.ibm.com> wrote:
> On Mon, 2018-01-15 at 10:24 +0000, Richard Sandiford wrote:
>> >> + for (int i = 0; i < midpoint; i++)
>> >> + {
>> >> + tree tmp1 = build_int_cst (lhs_type_type, offset + i);
>> >> + tree tmp2 = build_int_cst (lhs_type_type, offset + n_elts +
>> i);
>> >> + CONSTRUCTOR_APPEND_ELT (ctor_elts, NULL_TREE, tmp1);
>> >> + CONSTRUCTOR_APPEND_ELT (ctor_elts, NULL_TREE, tmp2);
>> >> + }
>> >> + tree permute = create_tmp_reg_or_ssa_name (lhs_type);
>> >> + g = gimple_build_assign (permute, build_constructor (lhs_type,
>> ctor_elts));
>> >
>> > I think this is no longer canonical GIMPLE (Richard?)
>>
>> FWIW, although the recent patches added the option of using wider
>> permute vectors if the permute vector is constant, it's still OK to
>> use the original style of permute vectors if that's known to be valid.
>> In this case it is because we know the indices won't wrap, given the
>> size of the input vectors.
>
> Ok.
>
>> > and given it is also a constant you shouldn't emit a CONSTRUCTOR
>> here
>> > but directly construct the appropriate VECTOR_CST. So it looks like
>> > the mergel/h intrinsics interleave the low or high part of two
>> > vectors?
>
> Right, it is an interleaving of the two vectors. The size and contents
> vary depending on the type, and though i briefly considered building up
> a if/else table, this approach was far simpler (and less error prone for
> me) to code up.
> i.e. (int, mergel) (permute) D.2885 = {0, 4, 1, 5};
> (long long, mergel) (permute) D.2876 = {1, 3};
I meant in the loop you could have populated a
auto_vec<tree> elts;
elts.safe_grow (n_elts * 2);
and use
permute = build_vector (lhs_type, elts);
to build a VECTOR_CST rather than going through a COSNTRUCTOR
and a separate assignment statement.
Richard.
> Thanks
> -Will
>
>
