On Tue, Jun 08, 2021 at 04:50:56PM +0100, Richard Sandiford wrote: > Segher Boessenkool <seg...@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
