cc65: Postincrementing is optimized wrong in some cases
In my project the following line of code is optimized wrong… see how the readpos post increment turns into a preincrement:
#define FILECOPY_BLOCKADDR 0x04c8
unsigned short readcnt;
unsigned char readpos;
;
; ((u8*)FILECOPY_BLOCKADDR)[readcnt++] = ((u8*)0xd702)[readpos++];
;
L0272:
; load readcount to a/x
lda _readcnt
ldx _readcnt+1
; save a/x
sta regsave
stx regsave+1
; inc a/x by one
jsr incax1
; store incremented value in readcount
sta _readcnt
stx _readcnt+1
; add saved value to 0x04c8 and store in sreg
lda #$C8
clc
adc regsave
sta sreg
lda #$04
adc regsave+1
sta sreg+1
; increment readpos
inc _readpos
; add readpos to 0xd702 and store in ptr1
ldx #$D7
lda #$02
clc
adc _readpos
bcc L0333
inx
L0333:
sta ptr1
stx ptr1+1
ldy #$00
lda (ptr1),y
sta (sreg),y
i compile using the following options:
DEFS=--add-source
DEFS+=--local-strings
OPTS=-Or
OPTS+=-Oi
OPTS+=-Os
OPTS+=--codesize 180
OPTS+=-W const-comparison,no-effect,struct-param,unknown-pragma,unused-label,unused-param,unused-var
leaving out the --codesize option “fixes” it, ie that is the source of the wrong optimization
Since i know for sure that it worked like this a while ago, i will start binsearching for the offending commit… stay tuned 😃
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 34 (34 by maintainers)
Commits related to this issue
- added various tests related to bug #1045 — committed to cc65/cc65 by mrdudz 4 years ago
Thanks, now even I see 😉
I’d be willing to merge a change doing so. I’d also be willing to merge a change doing this only for OptStackOps.
But I’d of course prefer very much to merge an OptStackOps fix (@acqn: hint hint).
interestingly… it was already there. adjusted the --help output to match what was already in the docs instead 😃
found
guess 767f093ff86604314a9ee42c25842c79905f3248 needs some fixing then…
@clbr: please have a look? 😃