Hi Richard, > No, define_subst works across patterns, keyed by attributes. Exactly > like > cond_exec, really. > > But what you ought to be able to do right now is > > (define_subst "ds_predicable" > [(match_operand 0)] > "" > [(cond_exec (blah) (match_dup 0))]) > > (define_subst_attr "ds_predicable_enabled" "ds_predicable" "no" "yes"0 > > (define_insn "blah" > [(blah)] > "" > "@ > blah > blah" > [(set_attr "ds_predicable" "yes") > (set_attr "ds_predicated" "<ds_predicable_enabled>")])
What would be the function of (set_attr "ds_predicable" "yes") ? Doesn't the use of <ds_predicable_enabled> already trigger the substitution? > > At which point you can define "enabled" in terms of ds_predicated plus > whatever. > > With a small bit of work we ought to be able to move that ds_predicated > attribute to the define_subst itself, so that you don't have to > replicate that > set_attr line N times. That would be nice. So we would have to use define_subst instead of define_cond_exec to generate the cond_exec patterns. But I'd like to keep using the "predicable" attribute the way it's used now to mark patterns for cond_exec'ednes. So you'd recommend changing the define_subst machinery to handle that ds_predicated attribute? I think that's more or less what you were > suggesting > with your cond_exec extension, yes? Pretty much, yes. Thanks for the explanation. > > > > r~