[RFC/PATCH 00/11] Fix up some unexpected empty split conditions

Richard Biener richard.guenther@gmail.com
Tue Jun 8 12:50:41 GMT 2021


On Tue, Jun 8, 2021 at 2:32 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> 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 &&?

Possible.  Maybe first enable a warning for the case with not starting
with "&& "
to give maintainers a chance to fix them and only then do the mass change
to separate define_insn and define_split to avoid churn in the .md files.  Well
maintained ports should be quick to fixup themselves.

And some cases might even be obvious.

Richard.

>
> Segher


More information about the Gcc-patches mailing list