On 05/20/2013 09:55 AM, Kyrylo Tkachov wrote: > For example, a setup like: > > (define_attr "predicated" "yes,no" (const_string "no")) > > (define_attr "control_attr" "yes,no" (const_string "yes")) > > > (define_attr "enabled" "no,yes" > (cond [(and (eq_attr "control_attr" "no") > (and (eq_attr "predicated" "yes") > (eq_attr "TARGET_RESTRICT_CE" "no"))) > (const_string "no")] > (const_string "yes")) > > (define_cond_exec > [(match_operator 0 "arm_comparison_operator" > [(match_operand 1 "cc_register" "") > (const_int 0)])] > "" > "" > [(set_attr "predicated" "yes")] // <<<< New field > ) > > (define_insn ... > [(set_attr "predicable" "yes") > (set_attr "control_attr" "yes,no")]) // <<<< disables predicated version of
We have a new define_subst which may help here. I *think* that define_cond_exec is (or is nearly) a subset of define_subst. On my medium term to-do list is to support define_cond_exec within gensupport via the define_subst infrastructure, removing everything except the actual parsing of define_cond_exec. Your "predicated" attribute could be mapped to a define_subst substitution. You could expose this via a true attribute, but I'm not 100% certain that you'd need to do so. I havn't thought about all of the ramifications here, but I'd be interested to hear about your thoughts or experiments down this line. r~
