Re: [Sdcc-user] missing possible optimizations?

[Scott D. <sc...@da...>]

On Tue, 8 Jul 2003, Erik Petrich wrote:
> On Mon, 7 Jul 2003, Josh Stone wrote:
> 
> > <test.asm snip>
> > 164:	mov	r3,a
> > 165:	mov	dptr,#(_FC_Commands + 0x0100)
> > 166:	movx	@dptr,a
> > 168:	mov	r3,#0x00
> > 171:	mov	a,r2
> > 172:	add	a,#_FC_Commands
> > 173:	mov	dpl,a
> > 175:	mov	a,r3
> > 176:	addc	a,#(_FC_Commands >> 8)
> > 177:	mov	dph,a
> > 
> > The entire use of r3 here is unnecessary.  There's a few optimizations that
> > would remove it completely.  First, line 164 is a dead store due to 168.
> > Constant propagation from 168 to 175 lets you simplify 175 to "clr a".  At
> > this point, the definition at 168 is now also dead code.
> 
> Code like this bothers me too, and I have been trying to come up with a
> good general solution for awhile. The root of this problem is that SDCC
> performs its dead code and constant propagation optimizations only at the
> intermediate code level and not at the assembly language register level.
> The redundancy in this sample of code were introduced by the back end code
> generator.

Actually, in the PIC port there is the pCode optimizer. It optimizes the 
assembly code in a way analgous to SDCC optimizes iCode. It's capable of 
removing unnecessary register accesses. The downside with pCode is that it 
only works with the PIC port.

I think that some of the functionality of the pCode optimizer can be 
integrated with the bulk of SDCC. This would require a major restructering 
in the way assembly code is generated (by the various gen.c's). Simple 
tasks like register live-range analysis could then be performed at compile 
time. However, to get the most out of a pcode-type optimizer, one would 
really need to move the functionality to the linker. 

Scott