https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #19 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Segher Boessenkool from comment #18) > (In reply to Uroš Bizjak from comment #15) > > 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. > > What unwanted condition? What limitation? "unwanted condition" refers to the usage of can_create_pseudo_p in the insn condition. "Limitation" refers to "the combiner expects exactly two new insn patterns to be generated".
