#1208 peephole - not replacing code from multiline macros

[dfulab]

Issue: If a code sequence tom be replaced is from a
multi-line macro, peephole doesn't see it.

Source: sdcc-src-2.6.0.tar.gz, Win32 VC++ 6.0. with the
following "fixes" to compile.
- fixing LF to CR/LF in VC++ project file: sdcc.dsw
- replacing references to "afxres.h" with "winres.h" in
support\scripts\resource.rc (VC++ issue when mfc not
installed)

How to reproduce it:
- Replace src\z80\peeph.def with supplied peeph.def and
Rebuild
- compile with command: sdcc -mz80 test.c
(ignore error messages as they are unrelated)

Input:
!ldahlsp macro (from src\z80\mappings.i) is used during
code generation
{ "ldahlsp",
"ld hl,#%d\n"
"\tadd\thl,sp" },

- peeph.def has one rule that targets the expanded code

replace {
ld hl,%1
add hl,sp
} by {
;fake test rule
ldahlsp %1
}

Output:
test.asm, lines: 53-56
add ix,sp
ld hl,#-2048 \ these are expanded macro
add hl,sp /
ld sp,hl

The expanded macro should have been replaced by
ldahlsp %-2048

(Note: ldahlsp is my made up instruction)

[dfulab]

test.c and peeph.def

[Borut Ražem]

Logged In: YES
user_id=568035

Fixed the first two issues:
- sdcc.dsw: changed property eol-style to CRLF
- support/scripts/resource.rc: replaced references to
"afxres.h" with "winres.h"

Borut

[Philipp Klaus Krause]

Logged In: YES
user_id=564030
Originator: NO

This is the same as RFE #1921731, which has some more details.

[Philipp Klaus Krause]

Fixed for z80/gbz80 in rev. #5673. I don't know about the situation on other ports.

Philipp

[Maarten Brock]

Apart from the disbanded i186 only the z80 uses a mappings.i file. I don't think any other port generates multiline asm instructions.

But I wouldn't call these macros because IMHO that is what is processed by the preprocessor. And what's worse, the preprocessor will still put multiline inline asm on one line as it removes the newlines. And thus the peephole optimizer still cannot process them correctly. Not for substitution, but also not for calculating the distance for replacing long jumps with short jumps! But this is already covered in several other bug reports. I think you can close this one.