Hi Richard, on 2021/6/2 下午4:11, Richard Sandiford wrote: > Kewen Lin <li...@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! BR, Kewen
