[PATCH] rtl: Join the insn and split conditions in define_insn_and_split

Segher Boessenkool segher@kernel.crashing.org
Tue Jun 8 16:06:41 GMT 2021


On Tue, Jun 08, 2021 at 04:50:56PM +0100, Richard Sandiford wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Tue, Jun 08, 2021 at 02:48:11PM +0200, Richard Biener wrote:
> >> > So yeah, patch withdrawn.  This on one hand is proof we do want to make
> >> > such a change, but on the other hand shows it needs more preparatory
> >> > steps.
> >> 
> >> I wonder if it makes sense to provide ports a means to opt-in into
> >> the strict "&& " requirement and thus we can gradually fix them.
> >> Probably requires some t-$target make fragment editing plus
> >> passing an extra arg to gen* based on that.
> >> 
> >> That way maintainers can gradually fix their ports and make sure
> >> they won't regress again.
> >
> > Just some target macro might be better / easier?  Just gensupport.c will
> > need to use it.
> >
> > Will we still allow empty split conditions?  And automatically make that
> > do the equivalent of "&& 1"?
> 
> Wouldn't that run the risk of the partial transition that my suggestion
> was rejected for? ;-)

First off, I have changed position a few times now on what I think would
be the best way forward here :-)

I assumed we would make the "&&" requirement a requirement for GCC 12
eventually.  But yes that needs to be spelled out!

> I think an empty define_insn_and_split split condition should continue
> to mean the same thing everywhere.  So while we continue to have ports
> in which an empty condition means one thing, I don't think we should
> also have ports where an empty condition means something else.

If we have the "&&" requirement, we either disallow empty split
conditions, or have it be treated as "&& 1".  In either case it will
mean the same thing everywhere.

And in all cases, not just these cases but *all* cases, code that works
on trunk will not necessarily work on backports.  I don't see any
obvious cases where this will be a worse problem with this, do you?


Segher


More information about the Gcc-patches mailing list