Wilco Dijkstra <wilco.dijks...@arm.com> writes: > Hi Richard, > >> That's because, once an instruction matches, the instruction should >> continue to match. It should always be possible to set the INSN_CODE of >> an existing instruction to -1, rerun recog, and get the same instruction >> code back. >> >> Because of that, insn conditions shouldn't depend on can_create_pseudo_p. > > We should never get into that state since it would be incorrect. If say we > created a movdf after regalloc that needs a split or a literal load, it cannot > match any alternative. So recog would fail.
But, as this series shows, it's possible to match new instructions after split1 and before can_create_pseudo_p returns false. And in general, we shouldn't rely on split1 for correctness. >> Yeah, I realise it's done by the split pass at the moment. My question was: >> why do we need to wait till then? Why can't we do it in expand instead? > > We could split at a different time. But why would that make a difference? > As long as we allow all FP immediates at all times in movsf/df, we end up > with the same issue. The idea was that, if we did the split during expand, the movsf/df define_insns would then only accept the immediates that their constraints can handle. >> Are there cases where we expect to discover new FP constants during RTL >> optimisation that weren't present in gimple? And if so, which cases are >> they? Where do the constants come from? > > These constants are created by undoing the previous split (using REG_EQUIV > to just create a new movsf/movdf instruction). When the split happened is not > relevant. Even using UNSPEC would not work as long as there is a REG_EQUIV > somewhere. Yeah, I realise that, which is why I think the expand approach would be more robust. It would in some ways be similar to what we do for symbolic constants. An alternative would be to add a constraint for the kind of constants that the split handles, and then use it in a new alternative of the move patterns. The split could then happen at any time, before or after reload. Thanks, Richard
