<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Gareth aka. Kit<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 05/05/2019 00:08, Ben Grasset wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL4d7Fhc8TV8ah=W9SwoJZ9ZBcDO-H8oWj8pROpCOnfPBWWZug@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Sat, May 4, 2019 at 5:31 PM J. Gareth Moreton
<<a href="mailto:gareth@moreton-family.com"
moz-do-not-send="true">gareth@moreton-family.com</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
I figure data-flow analysis will address everything
eventually, but I <br>
can't promise the compiler won't become very inefficient as
a result.<br>
</blockquote>
<div><br>
</div>
<div>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.*.</div>
<div><br>
</div>
<div>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."</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="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>