This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: H8/300H code size issues (RTX_COSTS)


Hi Toshi,

> > I added lots of insn patterns for the combiner to exploit and cut down
> > 411 lines, excluding labels, which amounts to more than 10% of the
> > original.
> > 
> > Although making the combiner happy isn't the only thing to do, I do
> > think that we have to teach h8300.md how to take advantage of the
> > how registers are configured.
> 
> Do you mean properly describe the intraregister byte- and word-moves, or
> are you referencing some other problem?

Yes, I meant the former.  But my concern is that describing those insn
patterns blows up h8300.md.

Looking at the code you sent me, I found that gcc produces horrible
code for a relatively common case like

unsigned long
m2r (unsigned char *p)
{
  return (((unsigned long) p[0] << 24)
	  | ((unsigned long) p[1] << 16)
	  | ((unsigned long) p[2] << 8)
	  | (unsigned long) p[3]);
}

This takes 27 assembly instructions when we could do the same with

	mov.b	@er0+,r2l
	mov.b	@er0+,r2h
	mov.w	r2,e0
	mov.b	@er0+,r2l
	mov.b	@er0,r2h
	mov.w	er2,er0
	rts

or with unaligned access,

	mov.l	@er0,er0
	rts

By the way, the above appears several times in your blowfish code.

Kazu Hirata


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]