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. > Plus define_independent_insn_and_split would act as a flag for something > that might be suspect. That always is a conceptual error, even. The name says so already: the insn and the split are very different things, with different conditions, they just happen to share a pattern. > If we split them then the define_split condition > will seem to have been chosen deliberately in isolation. And it will have beenm chosen deliberately! Why *else* write things like this? > > 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 :-) > > So the question is that: whether we need to demand an explicit "&&". > > Richard's proposal is for answer "no" which aligns with Richi's auto > > filling advice before. I think it would result in fewer changes since > > those places without explicit "&&" are mostly unintentional, all the jobs > > are done by implied "&&". Its downside seems to be bad readability, new > > readers may take it as two seperated conditions at first glance, but I > > guess if we emphasize this change in the document it would be fine? > > Or emitting one warning if missing an explicit "&&"? > > IMO the natural way to read it is that the split C condition gives the > conditions under which the instruction should be split. I think that's > why forgetting the "&&" is such a common mistake. (I know I've done it > plenty of times.) You even do in this description! :-) You do not want the define_split in a define_insn_and_split to happen for insns that do not match the insn condition, that would not be intuitive at all. > IMO requiring the "&&" is baking in an alternative, less intuitive, > interpretation. But you want the exact same semantics, right? I do agree that the syntax without "&&" looks nicer. It has many practical problems though, so it is nice to aim for, but we cannot move there until we have all existing machine descriptions fixed up first. Segher
