This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: cross gcc port problem
- To: "Oleg I. Vdovikin" <vdovikin at jscc dot ru>
- Subject: Re: cross gcc port problem
- From: Alan Lehotsky <apl at alum dot mit dot edu>
- Date: Mon, 19 Mar 2001 08:21:56 -0500
- Cc: "Alan Lehotsky" <apl at alum dot mit dot edu>, "Hans-Peter Nilsson" <hans-peter dot nilsson at axis dot com>, <gcc at gcc dot gnu dot org>
- References: <200103182136.WAA11584@ignucius.axis.se><p04330101b6db255f0162@[192.168.1.254]><009101c0b052$78e27dd0$4d28d0c3@jscc.ru>
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