This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Modifying ARM code generator for elimination of 8bit writes - need help
- From: Richard Sandiford <richard at codesourcery dot com>
- To: Wolfgang Mües <wolfgang at iksw-muees dot de>
- Cc: Rask Ingemann Lambertsen <rask at sygehus dot dk>, gcc at gcc dot gnu dot org
- Date: Tue, 06 Jun 2006 10:39:46 +0100
- Subject: Re: Modifying ARM code generator for elimination of 8bit writes - need help
- References: <200605282223.33002.wolfgang@iksw-muees.de> <200605312249.35517.wolfgang@iksw-muees.de> <20060604213637.GD10795@sygehus.dk> <200606051347.10616.wolfgang@iksw-muees.de>
Wolfgang Mües <wolfgang@iksw-muees.de> writes:
> On Sunday 04 June 2006 23:36, Rask Ingemann Lambertsen wrote:
>> On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
>> > > (define_insn "*arm_movqi_insn"
>> > > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
>> > > (match_operand:QI 1 "general_operand" "rI,K,m,r"))]
>
>> I think you should go back to this (i.e. the unmodified version) and
>> only change the "m" into "Q" in the fourth alternative of operand 0.
>> See if that works, i.e. generates addresses that are valid for the
>> swp instruction.
>
> No, that doesn't work:
>
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
>> __register_frame_info_table_bases':
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
>> satisfy its constraints: (insn 63 28 29 0
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:136 (set (mem/s/j:QI (plus:SI
>> (reg/v/f:SI 1 r1 [orig:102 ob ] [102]) (const_int 16 [0x10])) [0 S1
>> A32])
>> (reg:QI 12 ip)) 155 {*arm_movqi_insn} (nil)
>> (nil))
>> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: internal compiler error:
>> in reload_ cse_simplify_operands, at postreload.c:391
This is just a guess, but the insn above might be an output reload.
Reload instructions are not themselves reloaded. In other words,
if gcc needs to reload a QImode register out to a memory location,
it will assume that any m<-r move is OK; it will not restrict the
reload to Q<-r. This is by design. You can:
(1) Trap this in the movqi expander, if you can fix up the general
case without clobbering additional registers (unlikely).
(2) Define a reload_outqi pattern to handle general m<-r moves.
You then get a scratch register to play with. (This interface
has changed (and improved) since I last used it.)
(3) Modify reload so that output memory operands are legitimised
differently (only if you're brave).
(4) Restrict QImode addresses to 'Q'.
It looks downthread like you've already decided to do (4). I just
wasn't sure from the thread whether you realised that output reloads
might be a specific problem. Sorry in advance if this was just noise. ;)
Richard