On Thu, Dec 31, 2020 at 04:39:52PM +0000, Richard Sandiford wrote:
> Segher Boessenkool <seg...@kernel.crashing.org> writes:
> > 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.
>
> FWIW, the rtl-ssa stuff also tries to add this kind of clobber where
> necessary, meaning that fwprop now does too. But that's only a comment
> about those specific examples, not the general point.
>
> In both cases, adding the clobber is part of recognising an instruction,
> and can fail if the clobbered register is currently live. Then of
> course there's the decision about whether the split form is actually
> a win. So splits with clobbers would only conditionally succeed,
> even in passes that know how to add them.
>
> I agree with Uros that it seems unlikely that a pass would be allowed
> to split one pattern that doesn't match without checking whether the
> resulting instructions match, and without checking their cost.
Ah, okay, a define_split without define_insn is only valid in combine:
md.texi:
When the combiner phase tries to split an insn pattern, it is always the
case that the pattern is @emph{not} matched by any @code{define_insn}.
The combiner pass first tries to split a single @code{set} expression
and then the same @code{set} expression inside a @code{parallel}, but
followed by a @code{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 generated. It will verify that these patterns match some
@code{define_insn} definitions, so you need not do this test in the
@code{define_split} (of course, there is no point in writing a
@code{define_split} that will never produce insns that match).
So as long as people update the documentation whenever changing the
compiler, and your backend has no define_split that omits a clobber like
this for patterns that are also matched by a define_insn, all is good.
It is always hard to see if a splitter matches some other already
existing pattern (or whether a define_insn does, for that matter), but
that is a separate problem, much more general than this one.
Thanks for tolerating my worries,
Segher
