Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques and runtime checks Date: Thu, 9 May 2019 22:07:23 +0200 Organization: A noiseless patient Spider Lines: 38 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-077@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-046@comp.compilers> <19-05-052@comp.compilers> <19-05-068@comp.compilers> <19-05-072@comp.compilers> <19-05-075@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="52059"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, practice, comment Posted-Date: 10 May 2019 10:45:25 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Language: en-GB Xref: csiph.com comp.compilers:2312 > [For embedded applications there are systems where the object code > that the compiler generates is really the intermediate code from the > first pass of the compiler, and the linker reads everything in > including the libraries and does the optimization and code generation > on the whole thing.  Dunno how fast it is but it is my impression that > all of the code in the chips in your car was built that way. -John] There is a kernel of truth in there, but you are mixing a few things together. For some small microcontrollers, especially those with "brain-dead" processors like 8051 cpus, many toolchains do "whole program optimisation". For chips like these, you don't have a decent data stack (there are not "sp + offset" addressing modes), and ram is often in banks. To get efficient code, the compiler needs to try to fit local variables and parameters into static ram addresses, re-using them when possible, and consider code flow patterns when deciding which banks to use for different types of data. This is not done by a compiler and linker as you describe, but having a single program that takes all the C code from all the files, and treats it as a single unit (roughly speaking, you rename every file-static function and variable, adding the filename to the identifier, then make almost everything "static"). There are not separate compile and link stages. For larger processors (of which there are many in modern cars) using modern compilers, you can have "link time optimisation". Here each unit is handled by the compiler to produce a intermediary code in internal formats - but it is not just from the first pass. This code is analysed, warnings are generated when possible, and a large amount of optimisation is carried out while still in the internal formats. The linker then combines these (from many files), and passes the combination back to the compiler for further processing. For scalability, this can be done in repeated steps with different groups of files, rather than all at once - when building Firefox or LibreOffice, you want to take advantage of your 64-core build system. [Sounds reasonable. I was thinking of the ARM tools which I suppose do more than a tyrpical first pass before handing stuff off to the linker. -John]