On Thu, Dec 31, 2020 at 1:29 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > Hi! > > On Thu, Dec 31, 2020 at 09:54:01AM +0100, Uros Bizjak wrote: > > On Thu, Dec 31, 2020 at 9:40 AM Segher Boessenkool > > <seg...@kernel.crashing.org> wrote: > > > Nice. Just one thing: in principle the splitters can be used outside of > > > combine, too? This can lead to insns that do not recog() then? Is > > > there anything that prevents that from happening? > > > > No, combine splitters can't be used outside combine pass. These > > splitters only split non-recognizable (non-existing) instructions, and > > this is how they are told apart from general split insns. > > There is only a define_split, not also a define_insn that matches the > pattern (or a define_insn_and_split), but that is *not* unique to > splitters that are meant for combine. > > It isn't likely that any other pass would try to create this pattern, > but this isn't guaranteed, and such other passes do not necessarily do > the add-the-clobber (that is specific to combine, even!) Maybe fwprop > could create this insn, or something like Richard's new combine-like > pass.
I think that outside the combine pass, the insn should be recognized first, so a classic define_insn_and_split would work, but not define_split. IOW, other passes should only create valid insns. If this is not the case, the behavior should be documented, and we'll fix the splitters for this currently hypothetical problem. Uros.
