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: cross gcc port problem


At 11:56 AM +0300 3/19/01, Oleg I. Vdovikin wrote:

>Hello Alan,
>
>> The first problem is most likely patterns that in their worst case will
>require
>> three memory references, and you only have two available scratch index
>registers.
>    Can you explain what exactly do you mean? This processor and associated
>patterns has only one memory reference at a time. The most patterns on this
>machine is in the form "accumulator = accumulator op memory".


	Okay.  That sort of pattern won't cause a problem as long as accumulator is a hard register,
	unless the compiler decides it needs to spill the accumulator in order to generate
	reloads for the source.  [Single accumulator machines are BAD NEWS for gcc.  In fact, the
	port I'm doing for a single-accumulator machine does NOT track the accumulator as a hard
	register.  The DEFINE_INSN patterns are written with implicit use of the accumulator and
	it actually pretends to be a MEMORY-to-MEMORY machine]

> > You can find out more about the possible reasons by running the compiler
>under gdb and
>> doing
>>
>> call debug_reload()
>>
>> when it aborts with the spill failure (If I recall correctly, this abort()
>is in the middle of dealing
>> with reloads.
>    Ok, I will try this.
>
>> You might also look at the LEGITIMIZE_RELOAD_ADDRESS macro.  You may be
>able to "guide"
>> the compiler to generating better code for your machine.
>    Ok, I will examine this.
>
>> No.  That won't work, because  you CAN'T have any instructions between the
>CC setter
>> and the CC consumer or the compiler will crash.
>    You mean "any instructions" in the gcc sence? Insns? To be more clear
>here is the full definition of cmpqi insn:
>
>(define_insn "cmpqi"
>  [(set (cc0)
>        (compare (match_operand:QI 0 "register_operand" "r")
>                 (match_operand:QI 1 "general_operand" "m")))
>   (clobber (reg:QI 0))]
>""
>"
>    sub %1")

	Okay, this will work, because sets_cc0_p() knows how to dissect a PARALLEL.
	The simple idea using the DEFINE_EXPAND wouldn't because it doesn't normally
	make a parallel - although you can force it to, of course.

>
>.
>(define_insn "cmpqi"
>  [(set (cc0)
>        (compare (match_operand:QI 0 "register_operand" "r")
>                 (match_operand:QI 1 "general_operand" "m")))]
>""
>"
>    sub %1")
>
>    There is no clobber, so port works fine. But I'm not sure this safe
>because of one thing - if gcc decides to use reg:QI 0 - accumulator register
>for variable storing this code could destroy the content of it.

	That would seem to be a real risk.  I like the clobber in the parallel as a solution.

>
>Thanks for your suggestions,
>    Oleg.

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

		    Quality Software Management
		http://home.earthlink.net/users/~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]