On 8/11/23 10:30, Lehua Ding wrote:
> But combine doesn't run at -O0. So something is inconsistent. I
> certainly believe we need to avoid the mem->mem case, but that's
> independent of combine and affects all optimization levels.
This is an new bug when running all tests after fixing the combine bug.
OK. I must have misunderstood. Thanks for clarifying.
> I think we can simplify to just
> !(MEM_P (operands[0]) && MEM_P (operands[1])
> I would have expected those to be handled by the constraints rather than
> the pattern's condition.
Yeh, the condition of the V2 becomes much simpler after split.
That was the hope. It is worth noting that for simple moves eg movsi,
movdi, movsf, movdf, etc there is a requirement that a single insn
support all the valid combinations. But I don't think we've ever had
that requirement for vector modes and the situations where it's
important are much less likely to trigger for vector moves. Even more
so given how the cond_mov patterns are implemented for RISC-V.
Jeff
