Richard Biener <richard.guent...@gmail.com> writes: > 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.
Probably easiest to do something like can_vcond_compare_p, i.e.: machine_mode mode = insn_data[icode].operand[N]; rtx reg = alloca_raw_REG (mode, LAST_VIRTUAL_REGISTER + 1); … insn_operand_matches (icode, N, reg) … Thanks, Richard
