[05/nn] Add VEC_DUPLICATE_{CST,EXPR} and associated optab

[Richard Biener]

On Fri, Dec 15, 2017 at 1:52 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Fri, Dec 15, 2017 at 1:29 AM, Richard Sandiford
>> <richard.sandiford@linaro.org> wrote:
>>> This patch just adds VEC_DUPLICATE_EXPR, since the VEC_DUPLICATE_CST
>>> isn't needed with the new VECTOR_CST layout.  It's really just the
>>> original patch with bits removed, but just in case:
>>>
>>> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64-linux-gnu.
>>> OK to install?
>>
>> To keep things simple at this point OK.  Note that I'd eventually
>> like to see this as VEC_PERM_EXPR <scalar_type_1, scalar_type_1, { 0, ... }>.
>> For reductions when we need { x, 0, ... } we now have to use a
>> VEC_DUPLICATE_EXPR to make x a vector and then a VEC_PERM_EXPR
>> to merge it with {0, ... }, right?  Rather than VEC_PERM_EXPR <x_1, 0,
>> { 0, 1, 1, 1.... }>
>
> That's where the shift-left-and-insert-scalar thing (IFN_SHL_INSERT)
> comes in.  But yeah, allowing scalars as operands to VEC_PERM_EXPRs
> would mean it could represent both VEC_DUPLICATE_EXPR and IFN_SHL_INSERT.
> I guess the question is whether that's better than extending CONSTRUCTOR
> (or a replacement) to use the VECTOR_CST encoding.  I realise you don't
> like CONSTRUCTOR in gimple though...
>
> I promise to look at either of those for GCC 9 if you think they're
> better, but they'll be more invasive for other targets.

Thanks.
Richard.

> Thanks,
> Richard