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

Richard Sandiford richard.sandiford@arm.com
Tue Jun 8 16:45:15 GMT 2021


Segher Boessenkool <segher@kernel.crashing.org> writes:
> 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.

Ah, OK.  I meant that we shouldn't change what an empty condition means
until the transition is complete and the target macro has been removed.
If the question was instead whether we should allow an empty condition
once the transition is complete, then I've no opinion either way.
(It doesn't seem like something we need to decide now though.)

Thanks,
Richard


More information about the Gcc-patches mailing list