On Fri, Dec 04, 2020 at 07:32:43PM +0100, Uros Bizjak wrote:
> On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
> <seg...@kernel.crashing.org> wrote:
> > A splitter can *already* split to only one insn.
>
> Oh... brown paper bag time... I really don't know where and when I
> pick that info, since the docs indeed say:
At some point in the past it had to be always exactly two insns:
commit d340408c13f21efcbf7b012cfa7ccd3653b31281
Author: Richard Henderson <r...@cygnus.com>
Date: Mon Sep 18 11:08:19 2000 -0700
* combine.c (try_combine): Allow split to create a single insn.
That is a while ago though ;-)
But, the doc was fixed with
commit 8cb0906b0fa9c07095db1ec7fb22eaeecf5075af
Author: Segher Boessenkool <seg...@gcc.gnu.org>
Date: Wed Nov 6 01:06:23 2019 +0100
doc: Insn splitting by combine
(Many other places in the documentation still suggest splitters always
create multiple insns... That is the common case of course!)
> 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 one or two new insn patterns to be
(Before the 2019 commit, it said "exactly two".)
> 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--
>
> Enough compilers for today, I'd say.
Enjoy your weekend!
Segher
