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 in for.

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 <gar...@moreton-family.com <mailto:gar...@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to