On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote: > Richard Biener <richard.guent...@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 prudent. Segher
