[fpc-devel] Compile time functions

[Martok]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180720/5408117c/attachment.html>