On 13/6/24 下午11:43, Tom de Vries wrote: > Richard, > > I've noticed that f.i. *thumb2_alusi3_short has no explicit setting of the > conds > attribute, which means the value of the conds attribute for this insn is > nocond: > ... > (define_insn "*thumb2_alusi3_short" > [(set (match_operand:SI 0 "s_register_operand" "=l") > (match_operator:SI 3 "thumb_16bit_operator" > [(match_operand:SI 1 "s_register_operand" "0") > (match_operand:SI 2 "s_register_operand" "l")])) > (clobber (reg:CC CC_REGNUM))] > "TARGET_THUMB2 && reload_completed > && GET_CODE(operands[3]) != PLUS > && GET_CODE(operands[3]) != MINUS" > "%I3%!\\t%0, %1, %2" > [(set_attr "predicable" "yes") > (set_attr "length" "2")] > ) > ... > > AFAIU, this insn is either: > - conditional, and does not modify cc, or > - unconditional, and sets cc. > So the clobber of CC in the RTL conservatively describes both cases. > > It seems to me the logical conds setting for the conditional case is nocond, > set > (or perhaps clob) for the unconditional case. So, is this a more accurate > value > of conds for this insn: > ... > (set (attr "conds") > (if_then_else > (match_test "GET_CODE (PATTERN (insn)) == COND_EXEC") > (const_string "nocond") > (const_string "set")))] > ... > ? > > Is there a generic need to have this attribute accurate for all insns?
Following this thread that Tom pointed to me earlier in internal discussion: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00723.html If the short-CC-clobbered form is selected very late now, I think this pattern simply is (or should) not be used for the conditional (within IT-block) case. It should simply be set to "clob". Predicable might be set to "no" as well... Chung-Lin