#1955 Z80 very long compile even with low --max-allocs-per-node

open
z80 port (188)
Z80
3
2015-01-03
2012-02-29
Shiru
No

I ran into a known bug that makes SDCC completely unusable for me, so I thought to provide details just in case they could help to fix it eventually. It is in latest release version and snapshot builds.

The code was ~400 lines long when it started to compile ~10 seconds. At ~550 lines it compiles a minute. With --oldralloc it compiles fast, but one of functions does not work properly (it works when compiled without the option).

Code contains a long while(1) block with a break by a condition (main.c:531). If I remove the condition, compile time reduces greatly. If I move it to the while(..), the problem is back again.

sdcc -mz80 --code-loc 0x0006 --data-loc 0 --no-std-crt0 -I..\evosdk ..\evosdk\crt0.rel ..\evosdk\evo.rel --opt-code-speed --fomit-frame-pointer main.c -o %temp%\out.ihx

I provide all the files involved into the compile, hopefully I didn't miss something.

As a side note, in the past I sucessfully used 2.9.0 for a larger (2300 lines) and more complex project, perharps the problem was introduced later. I also attempted to compile current project with 3.0.0, it compiled fast, but didn't started at all, haven't investigated why.

Discussion

  • Philipp Klaus Krause

    When cmpilation speed matters, an alternative to --oldralloc is using --max-allocs-per-node with an argumnet lower than the default 3000.

    Philipp

     
  • Shiru

    Shiru - 2012-02-29

    Forgot to mention this, I also attempted to use --max-allocs-per-node instead of -oldralloc with values 2000, 1000, 500, 100, and even 10. With 100 and 10 it is ~10 seconds, which is still unacceptable for a project that is so small. With greater values it is way longer, I didn't count how much because it is impractical anyway.

     
  • Philipp Klaus Krause

    I fixed two --oldralloc bugs in revision #7393. Can you test if this fixes --oldralloc for you?

    Philipp

     
  • Shiru

    Shiru - 2012-03-02

    I can't test it with exactly the same code because the project is in active development (I moved back to 2.9.0 for now). However, in its current state it works as it should when compiled with --oldralloc in revision #7393.

     
  • Philipp Klaus Krause

    • priority: 5 --> 3
    • summary: Z80 very long compile time or incorrect resulting code --> Z80 very long compile even with low --max-allocs-per-node
     
  • Philipp Klaus Krause

    OK, I'll leave this open as a reminder about the too long compile time even for low values of --max-allocs-per-node.

    Philipp

     
  • Philipp Klaus Krause

    • Category: --> Z80
     
  • Philipp Klaus Krause

    • assigned_to: Philipp Klaus Krause
     
  • Philipp Klaus Krause

    So far progress on this issue looks good: An issue regarding maximal I-chains in Thorup's heuristic for obtaining tree-decompositions has been identified as the most likely cause. An evaluation of techniques from "Treewidth computations I" and the unpublished "Treewidth computations III" on control-flow graphs obtained from various benchmarks so far gave promising results regarding both the width of the resulting tree-decompositions and the runtime of the algorithms for obtaining tree-decompositions.
    However, the impact on compiler runtime and code quality has not been evaluated yet (this requires integration of the new techniques into sdcc, so far it was only done on the dumped cfgs obtained using --dump-graphs).

    Philipp

     

Log in to post a comment.