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. 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. 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.
