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
