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."
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.
Jakub
