This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Register constraints + and =
Jan Hubicka <hubicka@ucw.cz> writes:
>> "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.
>
> I believe I added use to make it clear that the insn does some other stuff with operand 5
> than just adding it to edx, i.e. that it specify the size of block copied.
> Without this it would be theoretically possible to change value of ecx when we need
> to do something with edx (i.e. if another value is later added to ecx, the optimizer
> may add the value to ecx before the memcpy)
I can accept the issue as a matter of documentation, but I don't
understand the rest. Remember that all the patterns are executed in
parallel. I don't see how adding a USE in parallel could affect
anything about how the operand is used.
Ian