From: SourceForge.net <no...@so...> - 2004-01-23 13:40:17
|
Feature Requests item #603246, was opened at 2002-09-01 22:53 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=603246&group_id=599 Category: None Group: None Status: Open Priority: 5 Submitted By: Wim Lewis (wiml) Assigned to: Nobody/Anonymous (nobody) Summary: Inefficient multiply by a constant Initial Comment: The following C code: xdata at 0x7FC6 char FOO; char fun(unsigned char tmp) { tmp = 2 * (tmp-1); return ((xdata char *)(&FOO))[tmp]; } is compiled inefficiently by the version of SDCC I got from CVS on 1-September-2002. My older copy of SDCC (2.2.1, which I'm trying to upgrade from) generates reasonably efficient code involving a decrement and an add. The new version (2.3.2-devel) generates much more elaborate code using an actual MUL instruction, instead of optimizing the MUL to an ADD. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2004-01-23 14:40 Message: Logged In: YES user_id=888171 Hello Frieder, You look with the eyes of the peephole optimizer. What I meant was more fundamental. This uses several temperary stores which it could do without. ; genReceive ;test.c:4: tmp = 2 * (tmp-1); ; genMinus ; genMinusDec ; Peephole 244.a moving first to a instead of r2 mov a,dpl mov r2,a ;REDUNDANT, never read back dec a mov r3,a ;REDUNDANT ; genCast mov r4,#0x00 ;REDUNDANT ;thrown away by next cast ;can also be postponed ; genLeftShift ; genLeftShiftLiteral ; genlshTwo mov a,r4 ;REDUNDANT xch a,r3 ;REDUNDANT add a,acc xch a,r3 ;REDUNDANT (1) rlc a ;REDUNDANT, or at least ;postpone CLR A to here mov r4,a ;REDUNDANT, thrown away ; genCast mov ar2,r3 ;REDUNDANT (1) ;test.c:5: return ((xdata char *)(&FOO))[tmp]; ; genPlus mov a,#0xC6 ;REDUNDANT (1) ; Peephole 236.a used r2 instead of ar2 add a,r2 ;OPTIMISE (1) add a,#0xC6 ;OPTIMIZED (1) mov dpl,a ; Peephole 240 use clr instead of addc a,#0 clr a addc a,#0x7F mov dph,a As you can see, this piece of code could have been 11 bytes shorter than the 30 it takes now. If you still want to be able to debug the code, storing in R2 would be nice but the rest can be optimized. Or can we even allocate local variables to A? Well, enough said. This is not what this RFE was about in the first place. Greetings, Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2004-01-22 23:24 Message: Logged In: YES user_id=589052 Hi Maarten, > , although more optimizations are always possible. what you're probably alluding to is the sequence with the redundant xch xch pair: ; genLeftShift ; genLeftShiftLiteral ; genlshTwo mov a,r4 xch a,r3 add a,acc xch a,r3 rlc a mov r4,a There is a peephole optimization to catch a similar case (peephole 252 for variables in direct data). Unfortunately it doesn't catch this one... While another peephole could be defined this is probably not the proper level to do it: there would have to be one for xdata, idata, and yes, some people would even want to left shift a long int too:) > , although more optimizations are always possible. Yeah, there is another one. And it would make sense to find a peephole optimization for it :^) This is it: mov r4,#0x00 ; genLeftShift ; genLeftShiftLiteral ; genlshTwo mov a,r4 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2004-01-22 19:54 Message: Logged In: YES user_id=888171 Dear developers, Tried this with SDCC 2.3.7 (2004-01-21) and it uses no MUL, only ADD A,ACC and RLC A along with the necessary MOV's. Produced code looks perfectly ok to me, although more optimizations are always possible. I think this RFE can be closed. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=603246&group_id=599 |