This is the mail archive of the
mailing list for the GCC project.
Re: Modifying ARM code generator for elimination of 8bit writes - need help
- From: Wolfgang Mües <wolfgang at iksw-muees dot de>
- To: Rask Ingemann Lambertsen <rask at sygehus dot dk>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 5 Aug 2006 21:03:34 +0200
- Subject: Re: Modifying ARM code generator for elimination of 8bit writes - need help
- References: <firstname.lastname@example.org> <20060720143740.GA10837@sygehus.dk> <20060721132658.GB20384@sygehus.dk>
On Friday 21 July 2006 15:26, Rask Ingemann Lambertsen wrote:
> I found that this peephole optimization improves the code a whole
> Another way of improving the code was to swap the order of the two
> last alternatives of _arm_movqi_insn_swp.
Anyway, the problems with reload continues...error: unrecognizable insn
First, I have had a problem with loading a register with a constant.
(no clobber). I have solved this problem by adding
> (define_insn "_arm_movqi_insn_const"
> [(set (match_operand:QI 0 "register_operand" "=r")
> (match_operand:QI 1 "const_int_operand" ""))]
> "TARGET_ARM && TARGET_SWP_BYTE_WRITES
> && ( register_operand (operands, QImode))"
> mov%?\\t%0, %1"
> [(set_attr "type" "*")
> (set_attr "predicable" "yes")]
I am very shure that this does only cure the symptoms, and it will
better to fix this in the reload stage, but at least, it worked, and I
was able to compile the whole linux kernel!
After testing that the kernel is running, I have tried to compile
uCLinux. And there is the next problem....
> ../ncurses/./base/lib_set_term.c: In function '_nc_setupscreen':
> ../ncurses/./base/lib_set_term.c:470: error: unrecognizable insn:
> (insn 1199 1198 696 37 ../ncurses/./base/lib_set_term.c:429 (parallel
> [ (set (mem/s/j:QI (reg/f:SI 3 r3 ) [0 <variable>._clear+0 S1
> ) (reg:QI 0 r0))
> (clobber (subreg:QI (reg:DI 11 fp) 0))
> ]) -1 (nil)
> ../ncurses/./base/lib_set_term.c:470: internal compiler error: in
> at recog.c:2020 P
The source code line is:
> newscr->_clear = TRUE;
Obviously, TRUE is loaded in r0, but I don't know why this construct
(storing a byte into a struct member referenced by a pointer) is not
I fear that these problems are creating an endless story, and sorry for
generating traffic on this list, because I'm still no gcc expert...
On the other hand, the compiler now has generated code from hundreds of
files, and maybe I'm very near to success now.
We're back to the times when men were men
and wrote their own device drivers.