https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #15 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Segher Boessenkool from comment #12) > (In reply to Uroš Bizjak from comment #10) > > Regarding reliability of pre-reload splitters, IIRC they should be safe, but > > I'll leave the final verdict to RTL experts. > > The *splitters* are just fine; a define_insn with a condition that turns off > in a later pass generally is not. Is it possible to lift the limitation from the combine pass, where the combine tries to split the insn, but expects exactly two new insn patterns to be generated. From the docs: --q-- When the combiner phase tries to split an insn pattern, it is always the case that the pattern is _not_ matched by any 'define_insn'. The combiner pass first tries to split a single 'set' expression and then the same 'set' expression inside a 'parallel', but followed by a 'clobber' of a pseudo-reg to use as a scratch register. In these cases, the combiner expects exactly two new insn patterns to be generated. It will verify that these patterns match some 'define_insn' definitions, so you need not do this test in the 'define_split' (of course, there is no point in writing a 'define_split' that will never produce insns that match). --/q-- Many define_and_split insns in i386.md that use can_create_pseudo_p have this unwanted condition in their insn condition just because of the mentioned limitation.
