[sdcc-devel] [ sdcc-Bugs-1076940 ] Optimizer produces bad code

[SourceForge.net <no...@so...>]

Bugs item #1076940, was opened at 2004-12-01 20:51
Message generated for change (Comment added) made by stsp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1076940&group_id=599

Category: None
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Stas Sergeev (stsp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optimizer produces bad code

Initial Comment:
Hi.

The following program is miscompiled by sdcc:
---
volatile unsigned short t = 0x8000;
 
unsigned short main()
{
  unsigned short a = t;
  unsigned char i = 2;
  while(i--) a = (a << 1) | (a >> 15);
  return a;
}
---

Expected result: 2
Actual result: 0

The asm code at fault is:
---
        mov     a,r2
        mov     acc.0,c
;       Peephole 112.b  changed ljmp to sjmp
        sjmp    00101$
---
What is missing is "mov r2, a" after "mov acc.0, c",
so the carry gets lost.

Test-case is attached.

----------------------------------------------------------------------

>Comment By: Stas Sergeev (stsp)
Date: 2004-12-04 20:33

Message:
Logged In: YES 
user_id=501371

OK, sorry, indeed there seem to be the side-effect. But I think
some other rules has the side-effects too (186.e?), so how is
it possible to find out when the side-effect is safe and when
not?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-12-03 23:59

Message:
Logged In: NO 

Hi Stas,
yes your peephole is _very_ compact. Unfortunately at the
end of the peephole the accumulator holds the 'other' byte
(the MSB byte instead of LSB byte). This interferes with
peephole 244.c on a function return:

;     genRLC
;       Peephole 254    optimized left shift
;     genRet
;       Peephole 244.c  loading dpl from a instead of r2
;       Peephole 261.a  optimized left rol
        mov     a,r3
        rlc     a
        xch     a,r2
        rlc     a
        xch     a,r2
        mov     acc.0,c
        mov     r3,a
        mov     dpl,a         <-- 
        mov     dph,r3
00101$:
        ret

My a little more brain dead approach is equivalent in code
size and speed (it's one instruction longer but doesn't use
a 2byte,2cycle instruction (mov acc.0,c)).

----------------------------------------------------------------------

Comment By: Stas Sergeev (stsp)
Date: 2004-12-03 21:03

Message:
Logged In: YES 
user_id=501371

Ah-ha, so here's the problem, how nice:)
By the way, shouldn't this operandsNotRelated() thing used
implicitly everywhere rather than only in 177.d?
Anyway, thanks guys for fixing it so quickly.

> Please also try the appended peepholes.
Tried. Well, dunno, perhaps it doesn't work as good as it
could. I wonder if using 3 rlc's for only 2 bytes isnt an
overkill. I removed one. Maybe the attached rule can
do better?

----------------------------------------------------------------------

Comment By: Frieder Ferlemann (frief)
Date: 2004-12-02 11:18

Message:
Logged In: YES 
user_id=589052

fixed. Should be in tomorrows snapshot.

Please also try the appended peepholes. Without compiling,
just additionally specify --peep-file peeph_rot.def on the
command line.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1076940&group_id=599