[PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]

[Richard Biener]

On Mon, Sep 14, 2020 at 12:47 PM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > On gimple the above function (after fixing it) looks like
> >
> >   VIEW_CONVERT_EXPR<int[4]>(u)[_1] = i_4(D);
> >
> > and the IFN idea I had would - for non-global memory 'u' only - transform
> > this to
> >
> >   vector_register_2 = u;
> >   vector_register_3 = .IFN_VEC_SET (vector_register_2, _1, i_4(D));
> >   u = vector_register_3;
> >
> > if vec_set can handle variable indexes.  This then becomes a
> > vec_set on a register and if that was the only variable indexing of 'u'
> > will also cause 'u' to be expanded as register rather than stack memory.
> >
> > Note we can't use the direct-optab method here since the vec_set optab
> > modifies operand 0 which isn't possible in SSA form.
>
> Would it be worth changing the optab so that the input and output are
> separate?  Having a single operand would be justified if the operation
> was only supposed to touch the selected bytes, but most targets wouldn't
> guarantee that for memory operands, even as things stand.

I thought about this as well, just didn't want to bother Xiong Hu Luo with
it for the experiments.

> Or maybe the idea was to force the RA's hand by making the input and
> output tied even before RA, with separate moves where necessary.
> But I'm not sure why vec_set is so special that it requires this
> treatment and other optabs don't.

Certainly the define_expand do not have to be define_insn so the target
can force the RAs hand just fine if it likes to.

The more interesting question of course is how to query vec_set whether
it accepts variable indices w/o building too much garbage RTL.

Richard.

>
> Thanks,
> Richard
>
>
> > That might hint at that we eventually want to extend BIT_INSERT_EXPR
> > to handle a non-constant bit position but for experiments using an
> > alternate internal function is certainly easier.
> >
> > Richard.