On Mon, Sep 14, 2020 at 12:47 PM Richard Sandiford <richard.sandif...@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.
