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

[<lic...@qq...>]

Sure, there is no simple and perfect solution for optimization cross multiple translation unit（.c file）.
If we want that it dose not affect the building sequence of SDCC C project，leave all the cross file optimization in link time (maybe include regenerating the .asm/.o file when linking).




------------------ Original ------------------
From:                                                                                                                        "Development chatter about sdcc"                                                                                    <ole...@t-...&gt;;
Date:&nbsp;Wed, Jul 3, 2024 08:39 AM
To:&nbsp;"Development chatter about sdcc"<sdc...@li...&gt;;

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



On Tue, 2024-07-02 at 19:08 +0200, Benedikt Freisen via sdcc-devel wrote:
&gt; 
&gt; I still favor the AspectC++ approach to whole program analysis because
&gt; of its simplicity:
&gt; 
&gt; Applied to SDCC, you would basically let the compiler analyze the source
&gt; code for each individual translation unit and let it write all the
&gt; information (function and variable usage, constant propagation etc.) to
&gt; a common database file (XML, JSON or whatever), but skip actual code
&gt; generation.

I'm not that familiar with the details, but that step sounds essentially
very similar to the LTO approach.&nbsp; It doesn't do the full compilation and
optimization of each translation unit, but just dumps the internal compiler
data structures at some set point.&nbsp; Since SDCC tends to slow down on larger
code sizes sooner, I'd rather avoid any fancy interoperable database formats
which add a (wasted) data marshaling round trip.

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

&gt; 
&gt; Eventually, you re-translate every translation unit one last time, this
&gt; time with global knowledge, and output optimized object files, which can
&gt; be linked using the same primitive linker as before.
&gt; 
&gt; I believe that the necessary changes to SDCC would be considerably less
&gt; invasive.
&gt; 

Sounds like that would require changing the build system of all the user
projects in order to benefit from it.&nbsp; Some folks might not be using
makefiles directly at all (e.g. me usually using cmake + ninja and/or make).
It might be less invasive on the SDCC side, but more invasive for all users
of SDCC, unless the build tools have built-in support for this approach.

Best regards,
Oleg Endo


_______________________________________________
sdcc-devel mailing list
sdc...@li...
https://lists.sourceforge.net/lists/listinfo/sdcc-devel