[RFC/PATCH 00/11] Fix up some unexpected empty split conditions

Segher Boessenkool segher@kernel.crashing.org
Wed Jun 2 23:52:17 GMT 2021

On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
> > So what Richard suggests would be to disallow split conditions
> > that do not start with "&& ", it's probably easy to do that as well
> > and look for build fails.  That should catch all cases to look at.
> Yeah.  As a strawman proposal, how about:
> - add a new "define_independent_insn_and_split" that has the
>   current semantics of define_insn_and_split.  This should be
>   mechanical.

I'd rather not have that -- we can just write separate define_insn and
define_split in that case.

How many such cases *are* there?  There are no users exposed to this,
and when the split condition is required to start with "&&" (instead of
getting that implied) it is not a silent change ever, either.

> - find the define_insn_and_splits that are missing the "&&", and where
>   missing the "&&" might make a difference.  Change them to
>   define_independent_insn_and_splits.
>   Like Richard says, this can be done by temporarily disallowing
>   define_insn_and_splits that have no "&&".

If we make that change permanently, that is all steps we ever need!

Very old backends use the same insn condition and split condition
sometimes still; it isn't hard to detect that as well, if that seems


More information about the Gcc-patches mailing list