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

[Rask Ingemann Lambertsen <rask at sygehus dot dk>]

On Sat, Aug 05, 2006 at 09:03:34PM +0200, Wolfgang Mües wrote:

> 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"
[cut]
> 
> 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!

Yes, it only cures the symptom, but it could take a lot of time to find the
cause, and the gain is small, so I think it is OK to leave it like this for
now.
 
> 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 [491]) [0 <variable>._clear+0 S1
> > A8]                                                                  
> >          ) (reg:QI 0 r0))
> >             (clobber (subreg:QI (reg:DI 11 fp) 0))
> >         ]) -1 (nil)
> >     (nil))
> > ../ncurses/./base/lib_set_term.c:470: internal compiler error: in
> > extract_insn,                                                        
> >                     at recog.c:2020 P

This insn was generated from the "reload_outqi" pattern. I don't completely
understand why it isn't recognized. The (subreg:QI (reg:DI 11 fp) 0) part
won't be matched by (match_scratch ...), but simplify_gen_subreg() should
have simplified it to (reg:QI 11 fp) since this is one of the main purposes
of having simplify_(gen_)subreg() in the first place. Try changing

   operands[3] = simplify_gen_subreg (QImode, operands[2], DImode, 0);

into

   operands[3] = gen_rtx_REG (QImode, REGNO (operands[2]));

(in "reload_outqi") and see if that works.

> 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...

You shouldn't be sorry about that. GCC provides a good, solid foundation
for learning something new every day.

> On the other hand, the compiler now has generated code from hundreds of 
> files, and maybe I'm very near to success now.

I think so too.

-- 
Rask Ingemann Lambertsen