"Robin Dapp" <[email protected]> writes: >>>> Grml, now I know why the issues disappeared... I accidentally >>>> re-introduced an older oversight in riscv's regmode_natural_size >>>> where I divided by 64 instead of by 8, leading to very limited >>>> coverage. >>>> I'll need at least two more hunks in expmed.cc and expr.cc both of which >>>> would be better off checking for a mov optab as well. Also, there is an >>>> ICE in simplify_subreg_concatn. >>> >>> Could you give an example of something that needs the new changes? >> >> The following two enter the infinite loop we talked about: >> gcc.c-torture/compile/pr85945.c compiled with -O3 -march=rv64gcv >> gcc.c-torture/compile/pr70355.c compiled with -O0 -march=rv64gcv >> >> There are more but I think these have two different signatures. > > Just would like to ask for clarification here, maybe I misunderstood. > Did you plan to give these failures a look yourself
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. 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. 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. Richard > or are you waiting for me to come up with a different approach?
