On Tue, Jun 08, 2021 at 09:08:56AM +0200, Richard Biener wrote: > On Tue, Jun 8, 2021 at 4:10 AM Kewen.Lin via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > on 2021/6/8 上午7:50, Segher Boessenkool wrote: > > > On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote: > > >> To find out those need fixing seems to be the critical part. It's > > >> not hard to add one explicit "&&" to those that don't have it now, but > > >> even with further bootstrapped and regression tested I'm still not > > >> confident the adjustments are safe enough, since the testing coverage > > >> could be limited. It may need more efforts to revisit, or/and test > > >> with more coverages, and port maintainers' reviews. > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572120.html > > > > > > This adds an "&&" everywhere (or in fact, it just skips any existing > > > one, it just has the same effect of adding it everywhere). I tested it > > > with building gcc and Linux for all supported targets (31 of them; I do > > > some with multiple configs, mostly 32-bit and 64-bit). None had any > > > difference before and after the change. > > > > > > So I am no longer worried that there will be any fallout from doing > > > this. There are many things that *could* go wrong, but I don't think > > > there will be enough at all to be an impediment to just throwing the > > > switch. > > > > > > If we go this way no target will need any significant fixing, maybe none > > > at all will be needed across all targets. And no changes will be needed > > > anywhere immediately. We could make leading "&&" deprecated, and the > > > same for split condition "1" (which was "&& 1"). This is easy to change > > > automatically as well. > > > > > Thanks very much for doing this! > > > > I guess we are not going to backport this? If we won't, it seems to need > > some way to ensure the implied "&&" will show up explicitly when backporting > > some define_insn_and_split. > > For this reason I'd prefer the explicit "&& ", Seghers testing means > mass-changing all define_insn_and_split is reasonable.
So mass-change all define_insn_and_split where the split condition is not inclusive of the insn condition (as written, i.e. before the iterators have added stuff), to be separate define_insn and define_split patterns? And *then* add the &&? Segher
