On 27/05/14 16:50, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
>> <quote>
>> The @code{enabled} insn attribute may be used to disable certain insn
>> alternatives for machine-specific reasons.
>> <quote>
>>
>> The rest of the text just says what happens when this is done and then
>> gives an example usage. It doesn't any time, either explicitly or
>> implicitly, say that this must be a static choice determined once-off at
>> run time.
>
> It says:
> "This definition should be based on other insn attributes and/or target
> flags."
<pedantry>
- It only says *should*, not *must*. "Should" can imply a
recommendation, not a requirement.
- It only says *based on*, not *solely based on*. Based on implies that
other information might be involved as well, without limitation.
</pedantary>
> where from what I understand Andreas originally meant was that the other
> insn attributes would be again based on target flags or other such insn
> attributes. Yeah, it explicitly rules out just basing the enabled attribute
> on
> the operands, arm uses just another attribute based on the operands there,
> but it still goes against the intent of the attribute, and is definitely a
> nightmare for the register allocator.
> Decisions based on the operands should be through constraints.
>
> From what I can see, arm uses it just on a single insn, so I'd say it
> shouldn't be a big deal to rewrite it.
>
Pedantry aside, I'm not against making such a restriction; but it is a
new restriction that isn't explictly stated in the documentation today.
R.
