On Tue, Nov 29, 2022 at 2:15 AM HAO CHEN GUI <guih...@linux.ibm.com> wrote: > > Hi Richard, > > 在 2022/11/29 2:46, Richard Biener 写道: > > Anyhow - my question still stands - what's the fallback for the callers > > that do not check for failure? How are we sure we're not running into > > these when relaxing the requirement that a MODE_CC prepare_cmp_insn > > must not fail? > > I examed the code and found that currently callers should be fine with > returning a NULL_RTX for MODE_CC processing. The prepare_cmp_insn is called > by following callers. > > 1 gen_cond_trap which doesn't uses MODE_CC > 2 prepare_cmp_insn itself where is after MODE_CC processing, so it never > hits MODE_CC > 3 emit_cmp_and_jump_insns which doesn't uses MODE_CC > 4 emit_conditional_move which checks the output is null or not > 5 emit_conditional_add which checks the output is null or not
Thanks for checking. > Not sure if I missed something. Looking forward to your advice. I'd then say the non-presence of the optab should be handled the same as a mismatching predicate as the other comment on the patch indicates. thanks, Richard. > Thanks a lot > Gui Haochen >
