Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Thu, Jun 03, 2021 at 09:05:02AM +0100, Richard Sandiford via Gcc-patches > wrote: >> Right. Plus it creates less make-work. If we didn't have it, someone >> would need to split the define_insn_and_splits that don't currently >> use "&&", then later someone might decide that the missing "&&" was a >> mistake and need to put them together again (or just revert the patch >> and edit from there, I guess). > > I would hope no maintainer would be foolish enough to flip-flop like > that.
But the point is that the maintainers wouldn't be flip-flopping. The move to define_independent_insn_and_split would be a mechnical change made by someone else. We shouldn't just add "&&" to all define_insn_and_splits that currently lack them. That might well break things. So to get the perfect result, someone has to look at each individual define_insn_and_split that currently lacks a "&&" to see what the effects of adding "&&" would be. IMO it's not reasonable to ask Kewen to do that for all ports. So the process I suggested was a way of mechanically changing existing ports in a way that would not require input from target maintainers, or extensive testing on affected targets. It would keep the behaviour of the port the same as it is now (whether that's good or bad). This part of the process could be scripted. >> > If I read the proposal right, the explicit "&&" is only required when going >> > to find all potential problematic places for final implied "&&" change. >> > But one explicit "&&" does offer good readability. >> >> I don't know. "&& 1" looks kind of weird to me. > > We have it in rs6000.md since 2004. sparc has had it since 2002. i386 > has had it since 2001. arm still does not have it :-) Sure, this syntax goes back 20 years. I don't think that answers the point though. The question was whether a split condition "&& 1" is more readable than a condition "", given that "" means "always" in other contexts. Given the choice, IMO "" is more readable and "&& 1" looks weird/inconsistent. Thanks, Richard
