Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Paul Brook <paul at codesourcery dot com>]

On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> Hello Rask,
>
> On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> > There may be a faster way of seeing if the modification is going to
> > work for the DS at all. I noticed from the output template
> > "swp%?b\\t%1, %1, [%M0]" that "swp" takes three operands. I don't
> > know ARM assembler, but you may be able to choose to always clobber a
> > specific register. Make it a fixed register (see FIXED_REGISTERS),
> > refer to this register directly in the output template and don't add
> > a clobber to the movqi patterns. IMHO, that's an acceptable hack at
> > an experimental stage. If the resulting code runs correctly on the
> > DS, you can then undo the FIXED_REGISTERS change and add the clobber
> > statements.
>
> I have tried this. No luck. Problem is the lack of addressing modes for
> the swp instruction. Only a simple pointer in a register (no offset, no
> auto-increment is allowed).
>
> After reading most of the gcc rtl documentation (and forgetting way too
> much..) I came up to the following conclusion:
>
> Splitting the insn
>
> (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"))]
>
> into 4 different insns:

No. This is completely the wrong approach. You should just change the valid 
QImode memory addresses, adding a new constraint if neccessary. You also need 
to tweak the reload legitimate address bits to obey the new restrictions.

For the record these hacks are unlikely to ever be acceptable in mainline gcc. 
They're relatively invasive changes who's only purpose is to support 
fundamentally broken hardware.

Paul