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

[Jeff Law]

On 6/3/2021 2:00 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
>> on 2021/6/3 上午7:52, Segher Boessenkool wrote:
>>>> - add a new "define_independent_insn_and_split" that has the
>>>>    current semantics of define_insn_and_split.  This should be
>>>>    mechanical.
>>> I'd rather not have that -- we can just write separate define_insn and
>>> define_split in that case.
>> Not sure if someone would argue that he/she would like to go with one shared
>> pattern as before, to avoid any possible differences between two seperated
>> patterns and have good maintainability (like only editing on place) and
>> slightly better efficiency.
> You only would do this if you have a different insn condition and split
> condition, which is a very important thing to know, it doesn't hurt to
> draw attention to it.  The efficiency is exactly the same btw,
> define_insn_and_split is just syntactic sugar.
>
> The whole point of requiring the split condition to start with && is so
> it will become harder to mess things up (it will make the gen* code a
> tiny little bit simpler as well).  And there is no transition period or
> anything like that needed either.  Just the bunch that will break will
> need fixing.  So let's find out how many of those there are :-)
Exactly.   While these empty conditions or those not starting with "&&" 
are technically valid, they're all suspicious from a port correctness 
standpoint, particularly if the main condition is non-empty.

Having made that mistake when converting the H8 away from CC0, I can say 
fairly confidently that if we had this in place a year ago that those 
mistakes would likely have been avoided.  Thankfully the H8 isn't a 
heavily used port and has limped along until I stumbled over the issue a 
week or so ago while polishing some improvements to the port.
Jeff