Re: Optimization techniques and runtime checks

David Brown <david.brown@hesbynett.no>
Thu, 9 May 2019 22:07:23 +0200

          From comp.compilers

Related articles
[5 earlier articles]
Re: Optimization techniques and runtime checks DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2019-05-08)
Re: Optimization techniques and runtime checks david.brown@hesbynett.no (David Brown) (2019-05-08)
Re: Optimization techniques and runtime checks bc@freeuk.com (Bart) (2019-05-08)
Re: Optimization techniques and runtime checks DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2019-05-08)
Re: Optimization techniques and runtime checks david.brown@hesbynett.no (David Brown) (2019-05-08)
Re: Optimization techniques and runtime checks bc@freeuk.com (Bart) (2019-05-09)
Re: Optimization techniques and runtime checks david.brown@hesbynett.no (David Brown) (2019-05-09)
Re: Optimization techniques and runtime checks robin51@dodo.com.au (Robin Vowels) (2019-05-11)
Re: Optimization techniques and runtime checks genew@telus.net (Gene Wirchenko) (2019-05-11)
Re: Optimization techniques and runtime checks david.brown@hesbynett.no (David Brown) (2019-05-12)
| List of all articles for this month |

From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.compilers
Date: Thu, 9 May 2019 22:07:23 +0200
Organization: A noiseless patient Spider
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> 19-04-021 19-04-023 19-04-037 19-04-046 19-05-052 19-05-068 19-05-072 19-05-075
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
Content-Language: en-GB

> [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]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.