RE: [PATCH][gensupport] Add optional attributes field to define_cond_exec

["Kyrylo Tkachov" <kyrylo dot tkachov at arm dot com>]

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~