<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks for the explanation. I still have a lot to learn with
some things. I guess when you compare yourself to the behemoths,
you're always going to look sloppy.</p>
<p>Things that come to mind that could be possible when I think
about whole-program optimisation and smart linking:<br>
</p>
<p>- Identification of duplicate functions. This is not always as
obvious as code duplication, but when I've compiled the compiler
before, I've noticed that a number of leaf functions compile into
the same machine code, which may be due to types that are
identical on a particular platform, or the elimination of code due
to preprocessor directives, for example. I imagine such
identification could be done via a hash table, and then doing a
more thorough check to see if there is an actual match or an
unfortunate collision. Admittedly a number of these routines are
inlined so it might not produce much of a saving in the real
world.</p>
<p>- Identifying functions that are only used once. This became a
slight point of contention between Florian and myself, because I
inlined a couple of functions in my jump optimisations that I was
absolutely certain were only called once elsewhere. When a
function is only called once, theoretically there's a slight speed
and size saving if the function is inlined at the call. I figure
it would require whole-program optimisation though because the
function call opcodes have already been implemented, while
inserting the raw nodes would yield more optimal code (better
register usage and cancelling out actual parameter set-up).
Theorising an implementation, calls that are 'noinline' or have
something that the compiler flags as 'cannot inline' would not be
optimised in this way, and assembler routines are intrinsically
'noinline' as well, so it covers that use case.<br>
</p>
<p>Thanks again for the education on what I don't know everything
about!</p>
<p>Gareth aka. Kit<br>
</p>
<div class="moz-cite-prefix">On 08/11/2019 16:15, Sven Barth via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFMUeB9OeJPm-nk1hZY9EV7yH2F_nYOA1YOdKj-vQgu8VPsN-Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">J. Gareth Moreton <<a
href="mailto:gareth@moreton-family.com"
moz-do-not-send="true">gareth@moreton-family.com</a>>
schrieb am Fr., 8. Nov. 2019, 14:28:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 08/11/2019 13:14, Sven Barth via fpc-devel wrote:<br>
> ...<br>
> What's stopping that? Simple: no driving need. It's
just work for <br>
> something that has essentially no gain.<br>
<br>
No gain? Wow, is whole-program optimisation that
underperforming? Given <br>
the bloated size of FPC's binaries compared to, say, what
a mainstream <br>
C++ compiler than do, I would have thought that there
could be a lot <br>
that could be stripped out in regards to unused functions
and the like. <br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Unused functions are handled by smart linking.
No need for WPO here. WPO is needed for devirtualisation for
example where the compiler is a very good usecase for due to
the architecture of the backend. For other real world
applications your mileage may vary. </div>
<div dir="auto">One possible further WPO task would be
deduplication of generic specializations for the same types
(at least unless the target also supports comdat sections). </div>
<div dir="auto">But all in all WPO isn't used that much in the
real world. </div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Or am I missing something? The large binary sizes feel
like an elephant <br>
in the room that no-one talks about. What causes them?<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Mainly RTTI and the fact that FPC provides a
statically linked RTL. Change MSVC to static linking and
suddenly you get 300 KB executables as well. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Back when I did the first tests with dynamic
packages the chmcmd binary only had 20 KB or so, but the
necessary package libraries were much bigger (and there smart
linking and WPO are both much less usable as they can only
strip stuff that is not exported). </div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards, </div>
<div dir="auto">Sven </div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
fpc-devel maillist - <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
</body>
</html>