On 02/01/2016 02:45 PM, Ulrich Weigand wrote: > Andreas Krebbel wrote: > >> With this patch a `disabled' attribute is defined which can be used to >> explicitly disable an alternative. This comes handy when defining the >> substitutions later and while adding it anyway I've used it for the >> existing cases as well. > >> +; Insn attribute with boolean value >> +; 1 to disable an insn alternative >> +; 0 or * for an active insn alternative >> +; an active alternative can still be disabled due to lacking cpu >> +; facility support >> +(define_attr "disabled" "" (const_int 0)) >> + >> (define_attr "enabled" "" >> - (cond [(eq_attr "cpu_facility" "standard") >> + (cond [(eq_attr "disabled" "1") >> + (const_int 0) >> + >> + (eq_attr "cpu_facility" "standard") >> (const_int 1) >> >> (and (eq_attr "cpu_facility" "ieee") > > So I'm wondering what the difference is between this and simply > overriding the default implementation of "enabled" per-insn? > > So instead of adding > (set_attr "disabled" "0,1")]) > to an insn, you might simply add instead: > (set_attr "enabled" "*,0")]) Not sure but wouldn't this mean that the value of the enabled attribute would then depend on the order of the set_attr for "enabled" and "cpu_facility" since one is defined on the value of the other?!
-Andreas-