# [fpc-devel] Compile time functions

```Hi all,

inspired by Kit's concept for pure functions, I had a deeper look at what inline
functions (and more importantly, the nodes involved in expanding them) can do.
Let me share my proof-of-concept (which may very well become a
'poof-of-concept'...). You can find my current working branch here
<https://github.com/martok/freepascal/compare/master...dev_inlining>.```
```
Instead of marking a function as 'pure' at declaration, I took another way: make
normal inlining firstpass flexible enough that any "accidentally" pure function
can be collapsed at the call site.
As an extension, I then propose a new intrinsic:

function ConstExpr(X: AnyType): AnyType;
If the expression X can be reduced to a constant, the node simplifies to
that constant.
Otherwise, fail compilation with E3203 Illegal Expression.

ConstExpr is basically pass-through for most expressions, but it allows us to
"call" functions /at parse time/, as long as these functions are pure and the
arguments are constant at the point of declaration.

Let me illustrate with an example:

program tinline3;

function sinc(x: Real): Real; inline;
begin
if X = 0 then
Result:= 1
else
Result:= sin(x) / x;
end;

const
s1 = constexpr(sinc(0.3));
s2 = constexpr(sinc(0));
var
u, v: Real;
begin
u:= s1;
u:= s2;
end.

This gets processed into the node tree (right at parse time):

*******************************************************************************
after parsing
\$main; Register;

*******************************************************************************
(blockn, resultdef = \$void = "untyped", pos = (16,1), loc = LOC_INVALID,
expectloc = LOC_INVALID, flags = [], cmplx = 4
(statementn, resultdef = <nil>, pos = (17,9), loc = LOC_INVALID,
expectloc = LOC_INVALID, flags = [], cmplx = 4
(assignn, resultdef = \$void = "untyped", pos = (17,3), loc =
LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 2
(loadn, resultdef = Real = "Double", pos = (17,3), loc =
LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_write], cmplx = 1
nil
symbol = U
)
(realconstn, resultdef = Real = "Double", pos = (17,7), loc =
LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 2
value =  9.85067355537798561294E-0001
)
)

)
(statementn, resultdef = <nil>, pos = (18,9), loc = LOC_INVALID,
expectloc = LOC_INVALID, flags = [], cmplx = 2
(assignn, resultdef = \$void = "untyped", pos = (18,3), loc =
LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 2
(loadn, resultdef = Real = "Double", pos = (18,3), loc =
LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_write], cmplx = 1
nil
symbol = U
)
(realconstn, resultdef = Real = "Double", pos = (18,7), loc =
LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 2
value =  1.00000000000000000000E+0000
)
)

)
)

As you can see, the expressions have been simplified into (the correct)
constants of type Double (Real for x86 is Double). Intermediate type conversions
(including potential loss of FP-precision) are handled correctly (there's a
sneaky int(0)<>real in the example).
This is already really useful for the most common application of macros with
parameters in C: calculating constants (like #define _IOC(inout,group,num,len)
(inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num))).

There are currently a few issues:

1. I extended the const propagation optimisation pass a bit. It had
restrictions on inlinen and realconstn that probably had a reason, but I
can't see it...
2. calln now does an automatic internal optconstpropagate pass when inlining.
This is to carry refs to constant temps a bit further down. That might in
fact be problematic because it could increase code size with multiple loads
and should probably not be done in general. But for this PoC, that was the
simplest way.
3. procs can only be inlined if their body has been fully parsed before the
call. This is actually kind of a problem because it limits usefulness for
the C-style constant-macro application.
4. The tricky part (same goes for pure functions) is actually finding out if
parameters of an inlined function are constants. optconstpropagate can track
that after the fact, but at that point the fun is already over. The best
solution I could think of is running some very primitive DFA along while
parsing, so that the firstpass can refer to that. Basically, if a symbol is
known to be constant, loads of it could be treated as constants of its
stored value for the purposes of simplify(). This is of course limited to
only local symbols, but still doesn't seem very practical...

So, it's far from perfect, but shows that there is some potential for
metaprogramming without the need for much new complexity (numstat is +59-5 at
the time of writing this). I suspect there is quite a lot that could be gained
from better constant propagation in general: most nodes can already simplify
themselves efficiently, but only if they know the arguments are constant.

What do you think?

Regards,
Martok

```
```_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
```
{"ft_lang_label":"__label__en","ft_lang_prob":0.8732306,"math_prob":0.97243243,"size":5061,"snap":"2023-14-2023-23","text_gpt3_token_len":1250,"char_repetition_ratio":0.17085229,"word_repetition_ratio":0.18447837,"special_character_ratio":0.30764672,"punctuation_ratio":0.18241042,"nsfw_num_words":0,"has_unicode_error":false,"math_prob_llama3":0.98917806,"pos_list":[0],"im_url_duplicate_count":[null],"WARC_HEADER":"{\"WARC-Type\":\"response\",\"WARC-Date\":\"2023-06-02T22:42:53Z\",\"WARC-Record-ID\":\"<urn:uuid:28c262b4-3457-4e1a-a702-4782b9db20dc>\",\"Content-Length\":\"14019\",\"Content-Type\":\"application/http; msgtype=response\",\"WARC-Warcinfo-ID\":\"<urn:uuid:aab21332-ba2f-4486-877c-db1e2f5c2d8a>\",\"WARC-Concurrent-To\":\"<urn:uuid:b5ef6154-eeb7-4014-8c29-86601e2e1ba5>\",\"WARC-IP-Address\":\"72.52.77.8\",\"WARC-Target-URI\":\"https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg36400.html\",\"WARC-Payload-Digest\":\"sha1:K5A5BWDZMHUETNMWJPM7RA436LSN5FXG\",\"WARC-Block-Digest\":\"sha1:O4JKHCVEQQFE5LT5GNVKJPPUYRXKNH6X\",\"WARC-Identified-Payload-Type\":\"text/html\",\"warc_filename\":\"/cc_download/warc_2023/CC-MAIN-2023-23/CC-MAIN-2023-23_segments_1685224648858.14_warc_CC-MAIN-20230602204755-20230602234755-00322.warc.gz\"}"}