From: <445...@qq...> - 2024-07-03 03:33:23
|
On Tue, 2024-07-02 at 19:08 +0200, Benedikt Freisen via sdcc-devel wrote: > > 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. I'm not that familiar with the details, but that step sounds essentially very similar to the LTO approach. 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. 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. > > 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. > Sounds like that would require changing the build system of all the user projects in order to benefit from it. 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 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). Best regards, Chunjiang Li ________________ 月明风清 445...@qq... |