[fpc-devel] Possible idea... "safe" subroutines/methods
J. Gareth Moreton
gareth at moreton-family.com
Sun May 5 05:11:01 CEST 2019
You may be right. Part of Pascal's legacy through Turbo Pascal, Delphi
and Free Pascal is its exceptionally fast compiler. For the more
complex optimisations like data-flow analysis and what I call a "deep
optimiser", there's nothing wrong with it taking a long time (so long as
it is not weeks!) just, as you said, you opt in and enable "highest
level optimisation", so the user knows what they're getting themselves
Some elements of data flow analysis are a little more difficult, like
with this idea of moving some global variables into more local storage
so as to improve performance, because there may be some sneaky tricks
done with pointers, var parameters or even assembly language that will
break the compiler's assumption.
One problem I do have with FPC and its optimiser is that -O4 is
specifically said that it may cause side-effects and even
tongue-in-cheek says "beware". To me, this is bad design because it
discourages the end users from using the option and if an optimisation
causes well-behaved code to suddenly start malfunctioning, then that is
a bug in my eyes. To me, I'd like -O4 to be that aggressive, deep
optimisation that may take a few hours on the largest of projects
(although in reality it will probably only be a few minutes), but which
isn't going to create something questionable that will break things.
It's partly why I was wondering about marking certain procedures or
variables as non-volatile so they can be moved to local storage without
having to do it programmatically and making the code unmaintainable. By
specifically telling the compiler "this value is thread-safe", it can
make those assumptions because you've assured it that you're not doing
something tricky with it, rather than attempting to let the compiler
work it out for itself (which is probably impossible) and hence assume
it's not thread-safe and hence volatile.
I will admit that I am one of those people who likes to reduce code size
where possible, but not at the expense of performance. My idea of
reducing code size comes from using more efficient encodings for certain
things (my first patch contribution changed "MOV RAX, x", where x <
2^32, to "MOV EAX, x", saving between 4 and 5 bytes each time, depending
on the register, reducing the compiler's EXE size by 50 Kb) and
stripping out dead code.
Gareth aka. Kit
On 05/05/2019 00:08, Ben Grasset wrote:
> On Sat, May 4, 2019 at 5:31 PM J. Gareth Moreton
> <gareth at moreton-family.com <mailto:gareth at moreton-family.com>> wrote:
> I figure data-flow analysis will address everything eventually, but I
> can't promise the compiler won't become very inefficient as a result.
> I mean no offense by this, and note that I think you've done more for
> FPC in the last year (or two years-ish maybe?) than many people ever
> have, but I must say that to me this kind of thinking is very wrong
> and a big, specific part of what holds FPC back. It's as though people
> constantly forget that *not everything* needs to be some immutable
> hardcoded part of the overall compilation process, permanently
> affecting everyone until the end of time. In reality you can implement
> *literally anything at all*, and even if it takes seven hours to run,
> as long as it is an opt-in optimization enabled via a command-line
> argument or compiler directive there's no logical reason for anyone to
> complain about it because, again, it's *opt-in.*.
> And don't even get me started on the subject of "people who care in
> any way whatsoever about the size of the FPC executable, even though
> they are running desktop hardware and a desktop OS, *not* embedded
> hardware with an embedded OS, and so it could not possibly matter in
> *any* practical way to them even if the FPC executable was 25x larger
> than it currently is."
> fpc-devel maillist - fpc-devel at lists.freepascal.org
This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel