Hi! On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote: > on 2021/6/3 上午7:52, Segher Boessenkool wrote: > >> - 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.
You only would do this if you have a different insn condition and split condition, which is a very important thing to know, it doesn't hurt to draw attention to it. The efficiency is exactly the same btw, define_insn_and_split is just syntactic sugar. The whole point of requiring the split condition to start with && is so it will become harder to mess things up (it will make the gen* code a tiny little bit simpler as well). And there is no transition period or anything like that needed either. Just the bunch that will break will need fixing. So let's find out how many of those there are :-) > > 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. My proposal is to always require && (or maybe identical insn and split conditions should be allowed as well, if people still use that -- that is how we wrote "&& 1" before that existed). Segher
