combination of read/write and earlyclobber constraint modifier

[Jeff Law]

On 07/02/14 00:23, Marc Glisse wrote:
> On Tue, 1 Jul 2014, Tom de Vries wrote:
>
>> On 01-07-14 21:58, Marc Glisse wrote:
>>>>> So my question is: is the combination of '&' and '+' supported ? If
>>>>> so,
>>>>> what is the exact semantics ? If not, should we warn or give an
>>>>> error ?
>>>> I don't think we can define any reasonable semantics for &+.  My
>>>> recommendation would be for this to be considered a hard error.
>>>
>>> Uh? The doc explicitly says "An input operand can be tied to an
>>> earlyclobber
>>> operand" and goes on to explain why that is useful. It avoids using
>>> the same
>>> register for other input when they are identical.
>>
>> Hi Marc,
>>
>> That part of the doc refers to the mulsi3 insn for ARM as example:
>> ...
>> ;; Use `&' and then `0' to prevent the operands 0 and 1 being the same
>> (define_insn "*arm_mulsi3"
>>  [(set (match_operand:SI          0 "s_register_operand" "=&r,&r")
>>        (mult:SI (match_operand:SI 2 "s_register_operand" "r,r")
>>                 (match_operand:SI 1 "s_register_operand" "%0,r")))]
>>  "TARGET_32BIT && !arm_arch6"
>>  "mul%?\\t%0, %2, %1"
>>  [(set_attr "type" "mul")
>>   (set_attr "predicable" "yes")]
>> )
>> ...
>>
>> Note that there's no combination of & and + here.
>
> I think it could have used (match_dup 0) instead of operand 1, if there
> had been only the first alternative. And then the constraint would have
> been +&.
Note carefully that match_dup requires the exact same operand or the 
insn will not be recognized.  A matching constraint allows different 
pseudos and relies upon the register allocator to assign the different 
pseudos to the same hard register.

>
> (by the way, in the same aarch64-simd.md file, I noticed some
> define_expand with constraints, that looks strange)
It sometimes happens when a define_insn is converted into a 
define_expand -- folks just forget to remove the pointless constraints.

jeff
>