Re: [sdcc-devel] About optmize multiple .c file compilation with SDCC

[Benedikt F. <b.f...@gm...>]

Am 02.07.24 um 04:31 schrieb Oleg Endo:
> Hi,
>
> On Thu, 2024-06-27 at 15:25 +0800, 月明风清 via sdcc-devel wrote:
>> Hi, all.
>> God!  It is very much difficult work to do to optimize multiple .C files project compiling with SDCC.
>> Can we use a seperate tool to analyze and compose multiple .C files into one .c file (but need remaining the debugging infomation), after the Single .C file generated，using SDCC compile it，then the SDCC can do more optimization such as use one byte to contain multiple bit variable.
>>
>> Has anyone has some idea about this question?
>>
> This is more or less what GCC does with LTO.  The individual files are
> compiled and instead ( or in addition to) the relocatable machine code it
> also stores a dump of the compiler's intermediate code (kind of precompiled
> code).  That is passed to binutils linker and the linker then will invoke
> the "linker plugin" which is again GCC itself.  Or something like that.
>
> I think it's a hack to stay compatible with the traditional compilation
> model.  But that's one way of doing it.
>
> There's also the https://llvm-mos.org/ project.  They're also doing a couple
> of whole-program optimizations.  For example they solve the problem of how
> to optimally allocate function arguments on stack vs. using shared global
> variables -- a common problem on 8-bit systems.  Maybe you can get some
> inspiration from that project.
>
> Best regards,
> Oleg Endo

I still favor the AspectC++ approach to whole program analysis because
of its simplicity:

Applied to SDCC, you would basically let the compiler analyze the source
code for each individual translation unit and let it write all the
information (function and variable usage, constant propagation etc.) to
a common database file (XML, JSON or whatever), but skip actual code
generation.

You then use a specialized make tool to keep re-translating translation
units until the database does not change any further.

Eventually, you re-translate every translation unit one last time, this
time with global knowledge, and output optimized object files, which can
be linked using the same primitive linker as before.

I believe that the necessary changes to SDCC would be considerably less
invasive.

-- Benedikt