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]

Re: rtl questions


At 11:46 AM -0400 7/19/01, Bahman Sistany wrote:

>Still feeling my way around...
>
>1) Could someone expalin how the the rtl template actually matches an
>insn? is it like a regular expression? or something smarter than that?

	It's a "shape" and "predicate" matching.

>for example in the arm.md I see
>(define_expand "movesi"
>  [(set (match_operand:SI 0 "general_operand" "")
>        (match_operand:SI 1 "general_operand" ""))]
>   ...
>And this is supposed to match the private define_insn:
>
>(define_insn "*movesi_insn"
>  [(set (match_operand:SI 0 "general_operand" "=r,r,r,m")
>        (match_operand:SI 1 "general_operand" "rI,K,mi,r"))]
>   ...

	If an rtl INSN is created via a call on gen_movesi(), then when the instruction recognizer
	is called, it will look for a SET with mode SI and operands that are SI's and satisfy the
	general_operand() predicate.  The register allocation passes use the constraints to determine
	what registers would best be allocated and to fix up instructions that didn't get an allocation that
	was compatible with the form of the actual machine instruction.  (The reload pass).

>
>So obviously the constraints don't count in the matching here(?). But
>how about the predicates? would a "memory_operand" that is less general
>than a "general_operand" match?

	Yes, as a register operand is normally considered to be a general operand.


>i.e. would this match the define_insn above?
>
>(define_expand "movesi"
>  [(set (match_operand:SI 0 "memory_operand" "")
>        (match_operand:SI 1 "general_operand" ""))]


	Yes.

>   ...
>
>
>2) Is it absolutley necessary to have a matching define_insn for a
>define_expand?

	If the compiler reaches register allocation with an INSN that doesn't match any define_insn,
	I'm pretty sure that the compiler will crash.

	Remember that DEFINE_EXPANDs produce multiple INSNS, and a DEFINE_INSN only matches a SINGLE
	INSN (which might be a PARALLEL).  It's also possible that a DEFINE_SPLIT can match an INSN and
	transform it into some other INSN before instruction recognition occurs.  But, I suspect that would be
	somewhat pathological.

> I cannot find any for say the cmpsi pattern in the pj.md
>or is it that I don't understand how the matching works (question 1
>above)?

	If you look carefully, the pj.md DEFINE_EXPANDs NEVER emit RTL!!  The "DONE" says the C code took
	care of the "expansion".  And in fact, what actually happens is that the conditional branch pattern
	grabs the operands and the mode from global variables pj_cmp_op0, pj_cmp_op1, pj_cmp_mode
	and generates a compare-and-branch INSN.

-- 
------------------------------------------------------------------------

		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
			apl@alum.mit.edu
			(978)287-0435 Voice
			(978)808-6836 Cell
			(978)287-0436 Fax

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation


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