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. > 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. > 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. Try my trivial example with -fno-schedule-insns and look at what happens before/after IRA. Cheers, Wilco
