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-

Reply via email to