On Thu, Nov 12, 2020 at 7:26 PM Uros Bizjak <ubiz...@gmail.com> wrote: > > On Thu, Nov 12, 2020 at 6:51 PM Uros Bizjak <ubiz...@gmail.com> wrote: > > > > > > Yes, removed 'code' and value_mode by checking VECTOR_MODE_P and use > > > > > GET_MODE_INNER > > > > > for value_mode. ".md expanders" shall support for integer constants > > > > > index mode, but > > > > > I guess they shouldn't be expanded by IFN as this function is for > > > > > variable index > > > > > insert only? Anyway, the v3 patch used VOIDmode check... > > > > > > I'm not sure what best to do here, as said accepting "any" (integer) mode > > > as > > > input is desirable (SImode, DImode but eventually also smaller modes). > > > How > > > that can be best achieved I don't know. > > > > I was expecting something similar to how extvM/extzvM operands are > > handled here. We have: > > > > Operands 0 and 1 both have mode M. Operands 2 and 3 have a > > target-specific mode. > > > > Please note operands 2 and 3 having a "target-specific" mode, handled > > in optabs-query.c as: > > > > machine_mode struct_mode = data->operand[struct_op].mode; > > if (struct_mode == VOIDmode) > > struct_mode = word_mode; > > if (mode != struct_mode) > > return false; > > > > > Why's not specifying any mode in the patter no good? Just make sure you > > > appropriately extend/subreg it? We can make sure it will be an integer > > > mode in the expander itself. > > > > IIRC, having known mode, expanders can use create_convert_operand_to, > > and the middle-end will do the above by itself. Also note that at > > least two targets specify SImode, so register operands are currently > > ineffective there. > > On a related note, the pattern is currently expanded as (see > store_bit_field_1 in expmed.c): > > create_fixed_operand (&ops[0], op0); > create_input_operand (&ops[1], value, innermode); > create_integer_operand (&ops[2], pos); > > I don't think calling create_integer_operand on register operand is > correct. The function comment says: > > /* Make OP describe an input operand that has value INTVAL and that has > no inherent mode. This function should only be used for operands that > are always expand-time constants. The backend may request that INTVAL > be copied into a different kind of rtx, but it must specify the mode > of that rtx if so. */
Ah, sorry - variable vec_set takes a different path, please disregard my last message. Uros.