RFA: cache enabled attribute by insn code

[Richard Earnshaw]

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.