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

Kewen.Lin linkw@linux.ibm.com
Wed Jun 2 08:37:00 GMT 2021

Hi Richard,

on 2021/6/2 下午4:11, Richard Sandiford wrote:
> Kewen Lin <linkw@linux.ibm.com> writes:
>> Hi all,
>> define_insn_and_split should avoid to use empty split condition
>> if the condition for define_insn isn't empty, otherwise it can
>> sometimes result in unexpected consequence, since the split
>> will always be done even if the insn condition doesn't hold.
>> To avoid forgetting to add "&& 1" onto split condition, as
>> Segher suggested in thread[1], this series is to add the check
>> and raise an error if it catches the unexpected cases.  With
>> this new check, we have to fix up some existing
>> define_insn_and_split which are detected as error.  I hope all
>> these places are not intentional to be kept as blank.
> I wonder whether we should instead redefine the semantics of
> define_insn_and_split so that the split condition is always applied
> on top of the insn condition.  It's rare for a define_insn_and_split
> to have independent insn and split conditions, so at the moment,
> we're making the common case hard.

Just want to confirm that the suggestion is just applied for empty
split condition or all split conditions in define_insn_and_split? 
I guess it's the former?  It's like what Richi suggested with
auto-filling, the semantics redefining will eliminate the over-fill
concern.  Thanks for the suggestion!


More information about the Gcc-patches mailing list