This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Register constraints + and =


"Paulo J. Matos" <paulo@matos-sorge.com> writes:

> On 04/05/12 19:48, Ian Lance Taylor wrote:
>
>> The i386 rep_movqi insn is an example:
>>
>> (define_insn "*rep_movqi"
>>    [(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
>>     (set (match_operand:P 0 "register_operand" "=D")
>>          (plus:P (match_operand:P 3 "register_operand" "0")
>> 		(match_operand:P 5 "register_operand" "2")))
>>     (set (match_operand:P 1 "register_operand" "=S")
>>          (plus:P (match_operand:P 4 "register_operand" "1") (match_dup 5)))
>>     (set (mem:BLK (match_dup 3))
>> 	(mem:BLK (match_dup 4)))
>>     (use (match_dup 5))]
>>    "!(fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])"
>>    "%^rep{%;} movsb"
>>    [(set_attr "type" "str")
>>     (set_attr "prefix_rep" "1")
>>     (set_attr "memory" "both")
>>     (set_attr "mode" "QI")])
>>
>
> Thanks for the discussion on this which was enlightening.
> The rep_movqi rule seems scarily like our block copy instruction.
> By looking at it, the question that arises is, why the (use (match_dup
> 5))? I thought this was used to tell gcc that an operand was going to
> be used in a way not specified by the rtl but operand 5 is specified
> elsewhere in the rtl so gcc doesn't seem to need that (use ...)
> rule. Is this redundant or not?

I believe the (use (match_dup 5)) is redundant.

The insn used to look like this:

 (define_insn "rep_movqi"
   [(set (match_operand:SI 2 "register_operand" "=c") (const_int 0))
    (use (match_operand:SI 5 "register_operand" "2"))
    (set (match_operand:SI 0 "register_operand" "=D") 
         (plus:SI (match_operand:SI 3 "address_operand" "0") (match_dup 5)))
    (set (match_operand:SI 1 "register_operand" "=S") 
         (plus:SI (match_operand:SI 4 "address_operand" "1") (match_dup 5)))
    (set (mem:BLK (match_dup 3))
        (mem:BLK (match_dup 4)))
    (use (reg:SI 19))]

Here the (use (match_operand:SI 5) ...) appeared early to specify the
predicate and constraints for operand 5 and to make it clear that it was
just the input side of operand 2.

This change


http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00877.html


Fri Sep 29 13:20:42 MET DST 2000  Jan Hubicka  <jh@suse.cz>

	* recog.c (recog_memoized): Rename to recog_memoized_1.
	* recog.h (recog_memoized): Rename to recog_memoized_1.
	(recog_memoized): New macro.
	* rtl.h (single_set): Rename to single_set_1
	(single_set): New macro.
	* rtlanal.c (single_set): Rename to single_set_1;  expect clobbers
	to be last.

	* i386.md (strmovsi_1, strmovhi_1 strmovqi_1):
	Do not use match_dup of input operands at outputs.
	Use register_operand for memory expression.
	(rep_movsi): Put use last, canonicalize.
	Use register_operand for memory expression.
	(rep_movqi): Put use last.
	Use register_operand for memory expression.
	(strsetsi_1, strset_hi_1, strsetqi_1): Do not use match_dup
	of input operands at outputs.  Use register_operand for memory
	expression.
	(rep_stossi): Put use last; canonicalize; fix match_dup in
	the address expression
	(rep_stosqi): Likewise.
	(memcmp expander): Update calls.
	(cmpstrsi_nz_1, cmpstrsi_1, strlensi_1): Avoid match_dups in
	the clobbers.

	* i386.md (fp_jcc_3, fp_jcc_4, jp_fcc_5): if_then_else operand is
	VOIDmode.
	(fp_jcc_4, fp_jcc_3): Refuse unordered comparisons.

put the predicate and constraints on the first use of operand 5, and
added the (use (match_dup 5)) at the end of the insn.  I think that that
change should have simply dropped the (use (match_dup 5)), as it was no
longer needed.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]