On Fri, Dec 15, 2017 at 1:52 PM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> On Fri, Dec 15, 2017 at 1:29 AM, Richard Sandiford >> <richard.sandif...@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