> -----Original Message----- > From: Richard Henderson [mailto:r...@redhat.com] > Sent: Tuesday, November 22, 2011 7:55 AM > To: Jiangning Liu > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [RFC] Use which_alternative in preparation-statements of > define_insn_and_split > > On 11/20/2011 07:34 PM, Jiangning Liu wrote: > > Hi, > > > > I find which_alternative can't really be used in preparation- > statements of > > define_insn_and_split, so can this be fixed like below? > > > > For example, I want to use which_alternative in the pattern below, > > > > (define_insn_and_split "*thumb2_movsicc_insn" > > [(set (match_operand:SI 0 "s_register_operand" "=r,r,r,r,r,r,r,r") > > (if_then_else:SI > > (match_operator 3 "arm_comparison_operator" > > [(match_operand 4 "cc_register" "") (const_int 0)]) > > (match_operand:SI 1 "arm_not_operand" "0,0,rI,K,rI,rI,K,K") > > (match_operand:SI 2 "arm_not_operand" "rI,K,0,0,rI,K,rI,K")))] > > "TARGET_THUMB2" > > "@ > > it\\t%D3\;mov%D3\\t%0, %2 > > it\\t%D3\;mvn%D3\\t%0, #%B2 > > it\\t%d3\;mov%d3\\t%0, %1 > > it\\t%d3\;mvn%d3\\t%0, #%B1 > > ite\\t%d3\;mov%d3\\t%0, %1\;mov%D3\\t%0, %2 > > ite\\t%d3\;mov%d3\\t%0, %1\;mvn%D3\\t%0, #%B2 > > ite\\t%d3\;mvn%d3\\t%0, #%B1\;mov%D3\\t%0, %2 > > ite\\t%d3\;mvn%d3\\t%0, #%B1\;mvn%D3\\t%0, #%B2" > > "&& reload_completed" > > [(cond_exec (match_dup 5) > > (set (match_dup 0) (match_dup 6)))] > > " > > { > > if (which_alternative >= 2 && which_alternative < 4) > > { > > ... > > } > > else if (which_alternative >= 4) > > Hmm, I guess. It seems a bit weird. > > It seems like you'd be better off *not* using define_insn_and_split, > actually, and instead using more specific tests on the separate > define_split than you would on the define_insn. >
Yes. That would be alternative solution I can accept. But I still want to know why we don't want to support this? I don't see any GCC documentation saying not allowing this usage. Or you might be thinking this change is not safe enough? Thanks, -Jiangning > I don't feel strongly about it though. I won't object if some other > rtl maintainer wants to approve this. > > > r~