Hi Richi/Richard/Jeff/Segher, Thanks for the comments!
on 2021/6/3 上午7:52, Segher Boessenkool wrote: > 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. > Not sure if someone would argue that he/she would like to go with one shared pattern as before, to avoid any possible differences between two seperated patterns and have good maintainability (like only editing on place) and slightly better efficiency. > 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. > 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. >> - 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! > 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 "&&"? BR, Kewen > 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 >
