This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
(i386) fix_truncdi_nomemory and earlyclobber '&'
- From: Denis Chertykov <denisc at overta dot ru>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 07 Apr 2002 11:38:40 +0400
- Subject: (i386) fix_truncdi_nomemory and earlyclobber '&'
While debug a new register allocator I have founded a strange thing in
i386 port.
(define_insn "fix_truncdi_nomemory"
[(set (match_operand:DI 0 "nonimmediate_operand" "=m,?r")
(fix:DI (match_operand 1 "register_operand" "f,f")))
----------------------------^^^^
(use (match_operand:HI 2 "memory_operand" "m,m"))
(use (match_operand:HI 3 "memory_operand" "m,m"))
(clobber (match_operand:DI 4 "memory_operand" "=m,m"))
(clobber (match_scratch:DF 5 "=&1f,&1f"))]
-----------------------------------^---^
"TARGET_80387 && FLOAT_MODE_P (GET_MODE (operands[1]))
&& (!SSE_FLOAT_MODE_P (GET_MODE (operands[1])) || !TARGET_64BIT)"
"#"
[(set_attr "type" "fistp")])
operand[5] of "fix_truncdi_nomemory" insn have a constraint
'=&1' this seems wrong for me because description of '&' are
-----------Fragment from gcc info --------------------------------------
`&'
Means (in a particular alternative) that this operand is an
"earlyclobber" operand, which is modified before the instruction is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
finished using the input operands. Therefore, this operand may
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
not lie in a register that is used as an input operand or as part
of any memory address.
------------------------------------------------------------------------
IE: operand[1] can be "modified before the instruction is finished
using the input operands" if operand[5] will satisfy "=&1".
It's a bug.
How to understands '=&1' if it's not a bug ?
Denis.