#1208 peephole - not replacing code from multiline macros

closed-fixed
5
2010-02-05
2006-10-04
dfulab
No

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)

Discussion

  • dfulab
    dfulab
    2006-10-04

    test.c and peeph.def

     
    Attachments
  • Borut Ražem
    Borut Ražem
    2006-10-05

    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

     
  • Logged In: YES
    user_id=564030
    Originator: NO

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

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

    Philipp

     
  • Maarten Brock
    Maarten Brock
    2010-02-05

    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.

     
    • assigned_to: nobody --> spth
    • status: open --> closed-fixed