[preliminary patch] Optimize mov in h8300 port (revised!)

Jeffrey A Law law@cygnus.com
Tue Oct 17 08:59:00 GMT 2000


 In message <200010171341.GAA17195@cygnus.com>you write:
  > The following is the source code, based on fsetpos.c in newlib.  In my
  > patch, I considered the fact that loading a small constant is more
  > expensive than adding a small constant.  Of course, adding 0 goes
  > away, removing one branch and one basic block below.
  > 
  > int foo (int);
  > 
  > int
  > test ()
  > {
  >   int x = foo (0);
  > 
  >   if (x != 0)
  >     return 1;
  >   return 0;
  > }
  > 
  >  _test:
  >  	sub.w	r0,r0
  >  	jsr	@_foo
  >  	mov.w	r0,r0
  >  	beq	.L3
  >  	mov.w	#1,r0
  > -	bra	.L2
  >  .L3:
  > -	sub.w	r0,r0
  > -.L2:
  >  	rts
  > 
  > I used reload_completed to make no difference between move and add
  > until reload is completed, but that disabled transformations like the
  > above.  Other simple ones (a single replacement of move with add) were
  > OK.
CSE should have caught this case regardless of the definition of CONST_COSTS;
in fact it has an amazing amount of code that has the sole purpose is detecting
this kind of situation.  You should look into why CSE doesn't always detect
this optimization opportunity.





More information about the Gcc-patches mailing list