On 27/05/14 16:27, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
>> On 27/05/14 15:08, Richard Sandiford wrote:
>>> Hmm, is this because of "insn_enabled"? If so, how did that work before
>>> the patch? LRA already assumed that the "enabled" attribute didn't depend
>>> on the operands.
>>
>> Huh! "enabled" can be applied to each alternative. Alternatives are
>> selected based on the operands. If LRA can't cope with that we have a
>> serious problem. In fact, a pattern that matches but has no enabled
>> alternatives is meaningless and guaranteed to cause problems during
>> register allocation.
>
> This is not LRA fault, but the backend misusing the "enabled" attribute
> for something it wasn't designed for, and IMHO against the documentation
> of the attribute too.
> Just look at the original submission why it has been added.
>
> Jakub
>
<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.
That being said, I agree that this particular use case is pushing the
boundaries -- but that's always a risk when the boundaries aren't
clearly defined.
A better solution here would be to get rid of all those match_operator
patterns and replace them with iterators; but that's a lot of work,
particularly for all the conditinal operation patterns we have. It
would probably also bloat the number of patterns quite alarmingly.
