#3102 z80 peephole 77b breaks code?

[Philipp Klaus Krause]

Current FUZIX doesnÄt compile with current SDCC: taylormade.c compiles to invalid .asm. There is invalid asm in 6 places. I checked the first 4, and all are places where peephole rule 77b got applied.

To reproduce: Check out current FUZIX and build it.

[Philipp Klaus Krause]

Here is a small code sample, that, compiled with sdcc -mz80 test.c reproduces the issue.

[Sergey Belyashov]

77b cannot break anything. It just removes redundand zero after absolute value:

replace {
    ld  %1, (#%2 + 0)
} by {
    ; common peephole 77b removed unnecessary +0 to immediate
    ld  %1, (#%2)
}

[Philipp Klaus Krause]

I think the problem happens when %2 is already an expression with parentheses around it.

Maybe the assembler doesn't like double parentheses around an expression, so it would accept e.g. (#(x + 1) + 0), but not (#(x + 1)).

[Sergey Belyashov]

I think, it is bug of assembler itself. The rule can be temporary commented out.

[Philipp Klaus Krause]

I guess the assembler interprets the extra parentheses as an indirection.
In [r11836] I disabled the peephole rule for now.

[Sergey Belyashov]

Why have you disabled rule 44? 77b and 77c should be disabled only.

[Philipp Klaus Krause]

Peephole 44 breaks the same code.

The assembler accepts

ld  a, (#(_Flag + 0x0003) + 0)

but not

ld  h, (#(_Flag + 0x0003) + 0)

Since the outer parentheses make this a load from memory, not from an immediate. The Z80 has ld a, (nn), but not ld h, (nn).
Maybe rule 44 just needs a canAssign condition?

[Sergey Belyashov]

Yes. canAssign is required here.

[Sergey Belyashov]

I have reenabled rule 44 after adding canAssign: [r11839].