[fpc-devel] Possible idea... "safe" subroutines/methods

[J. Gareth Moreton]

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 
> <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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190505/935b337e/attachment.html>