Robin Dapp <rdapp....@gmail.com> writes: > What also works is something like: > > scalar_mode extract_mode = innermode; > if (GET_MODE_CLASS (outermode) == MODE_VECTOR_BOOL) > extract_mode = smallest_int_mode_for_size > (GET_MODE_PRECISION (innermode)); > > however > >> So yes, I guess we need to answer BImode vs. QImode. I hope Richard >> has a better idea here? > > aarch64's predicate vec_extract is: > > (define_expand "vec_extract<vpred><Vel>" > [(match_operand:<VEL> 0 "register_operand") > (match_operand:<VPRED> 1 "register_operand") > (match_operand:SI 2 "nonmemory_operand") > ;; Dummy operand to which we can attach the iterator. > (reg:SVE_FULL_I V0_REGNUM)] > > So if I'm reading this correctly they are using the element > mode of the associated full vector mode for extraction rather > than QImode. > > I could also do something similar for the riscv backend but > that still wouldn't yield a BImode vec_extract result of course > and expmed would need to be adjusted. Do we even know the > original associated non-predicate mode here? I suppose not? > > Do we need a mov from/to BImode instead? > > Maybe Richard has a good idea. > > Even though I haven't seen it being hit, vec_set in expmed > would have the same problem?
The patch seemed to be doing three things: - Use GET_MODE_PRECISION instead of GET_MODE_BITSIZE. I agree that this makes sense on the face of it. - Change the second mode to vec_extract_optab. This is only a name lookup, and it seems more natural to continue using the real element mode. - Change the mode of the output operand. Here we could use insn_data[icode].operand[0].mode instead of innermode. Thanks, Richard
