> Yeah, that was the idea, sorry, but I kept putting it off. > > I suppose this is all due to the RISC-V decision to forbid integer modes > in vector registers. For example, V2SI is a valid mode but SI and DI > are not. If integer modes were allowed, it would make sense to define > a TI move pattern and make the vr alternatives behave like V4SI. > TARGET_SECONDARY_MEMORY_NEEDED could say that moves between general > registers and vector registers must go via memory.
Yes, that's my understanding. If we had TI, etc. move patterns we would never loop but emit_move_multi_word could perform something sensible. Also, it's not like the RISC-V decision was to deliberately not introduce them. We just didn't see the need for it, initially. If at all, then the rationale was "getting scalars to/from vector registers is slow and rare, so let's not bother and have the middle-end spill as required". Through other ways, I guess crypto/crc, we started defining the larger integer modes then, but without introducing move patterns. On the one hand, I don't see any major obstacles just adding the moves but if we do that, I feel the documentation would need to be amended to indicate why it's necessary to have them. (I wouldn't know where and how, though :) ) On the other hand I'd prefer expmed/expand to handle the situation properly and if we're touching it anyway, let's do it (mostly) right. > The reason I'm hesistant about the new patch is that bitfield > insertion and extraction are relatively complex operations, involving > shifts, ANDs, and insv/extv patterns. In contrast, > operand_subword(_force) and emit_move_insn are supposed to be > relatively simple. Having the latter call the former feels like a > layering violation to me. Understood and understandable. We could also just spill directly (so the insertion/extraction risk is averted) in operand_subword_force and move_multi_word for the problematic cases? This still feels ad-hoc but maybe not at the wrong layer at least. I'll try something like this still if I have time. > Let me think about it a bit more. I'll back away for a few days, > so it will again be a slow reply, sorry. No need to be sorry, I'll be away as well for two weeks. But there's another thread I'd like to ping you before that :) -- Regards Robin
