[fpc-devel] inline... and philosophy

Sven Barth pascaldragon at googlemail.com
Fri Nov 8 17:15:42 CET 2019


J. Gareth Moreton <gareth at moreton-family.com> schrieb am Fr., 8. Nov. 2019,
14:28:

>
> On 08/11/2019 13:14, Sven Barth via fpc-devel wrote:
> > ...
> > What's stopping that? Simple: no driving need. It's just work for
> > something that has essentially no gain.
>
> No gain? Wow, is whole-program optimisation that underperforming? Given
> the bloated size of FPC's binaries compared to, say, what a mainstream
> C++ compiler than do, I would have thought that there could be a lot
> that could be stripped out in regards to unused functions and the like.
>

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.
One possible further WPO task would be deduplication of generic
specializations for the same types (at least unless the target also
supports comdat sections).
But all in all WPO isn't used that much in the real world.

Or am I missing something?  The large binary sizes feel like an elephant
> in the room that no-one talks about.  What causes them?
>

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.

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).

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20191108/a23dcef2/attachment-0001.html>


More information about the fpc-devel mailing list