Non lineal increment of compile times in some units.

[Miguel Angel Perez Martinez]

Hello! Now that my project is getting bigger I'm finding that some files sometimes cross a threshold where compilation changes from a couple of seconds to minutes. Even using quite low max-allocs-per-nodesettings. I have no idea why it happens. Is there any way to profile the compiling process to at least pinpoint where it's spending it's time? If it's just a tradeoff of how the compiling/optimization works I have no problem splitting functions or making changes to code to make it easier for the compiler but I'd like to know what is tripping it.

[Benedikt Freisen]

Since SDCC effectively compiles on a per-function basis, keeping functions short is usually a good strategy. I am not aware of any integrated profiling capabilities beyond --cyclomatic.

[Philipp Klaus Krause]

There is [bugs:#3884].
In my experience, global common subexpression elimination (GCSE) can get very slow when functions become big (big after macro expansion and inlining). And unlike register allocation and lospre, where we have --max-allocs-per-node for the compilation time / code quality trade-off, or generalized constant propagation, where there is a similar, but not user-configurable bound, GCSE will just keep going until it is done.

[Bert Lange]

Is there a description for the numbers of cyclomatic?
I got this numbers for example:

main.c:183: info 121: function 'main', # edges 181 , # nodes 129 , cyclomatic complexity 54
main.c:740: info 121: function 'timer_isr', # edges 1 , # nodes 2 , cyclomatic complexity 1
main.c:754: info 121: function 'rom_off', # edges 1 , # nodes 2 , cyclomatic complexity 1
main.c:761: info 121: function 'rom_on', # edges 1 , # nodes 2 , cyclomatic complexity 1