1. pure function value to constants function foo(i:longword):longword; pure; begin   foo:=9; end; const bar = foo( 8 );  //-- not allowed.. but i expect this to work!          jar : longword = foo( 7 ); //-- and this as well 2. this does not end grasefully function foo (i:longword):shortstring; pure; var s : shortstring;       n : longword; begin   s:=''';   for n:=1 to i do s:=s +'a';   //-- not assing return value end; begin writeln(foo(9)); end. 3. function foo (i:longword):ansistring; pure; var s : shortstring;       n : longword; begin   s:=''';   for n:=1 to i do s:=s +'a';   foo:=s; //-- this makes function not pure, but why whould it! end; begin writeln(foo(9)); end.  

Hi Marģers,

Thanks for the feedback!

Assigning the results of pure functions to constants has not yet been developed.  I had planned to add it once the bulk of pure functions (i.e. the current merge request) had been approved since it requires some additional work (specifically what happens if the function is not actually pure or otherwise can't return a straightforward result).

2 and 3 are definite bugs though.  The second case should at the very least make the function impure, while the third case should indeed not disqualify the function.  I'll see what I can do. Thanks again.

Kit

Fixed 2 and 3.

- 2 was due to not handling block nodes properly when they didn't have any statements (data-flow analysis stripped the procedure completely clean since no result was set), hence an access violation occurred while accessing a node that was nil.

- 3 was a two-fold problem:

1. The functiuon being ineligible was because a typeconv node couldn't be stripped out and so the final assignment tree wasn't in an expected format.  The analysis code now specifically permits this form of type conversion (convtype = tc_equal and identical resultdefs between the typeconv and the load nodes).
2. The second problem was due to a small hack where implicit Result parameters were converted from var to out so data-flow analysis worked properly, but they weren't converted back to var parameters afterwards, causing an access violation elsewhere in the code.

Merge request has been updated - I have also added two new tests based on your examples.  Thanks again Marģers.

Kit

I had a question about pure functions. I'm seeing some newer languages have a JIT built-in so they can run any function at compile time. To get results at compile time you probably need to use a constant for the parameters but in theory it could read/write to global variables so it's not really "pure" but still makes it possible to run functions at compile time.

How does this compare to pure functions? It seems like the JIT is actually easier to implement than all this complicated node analysis, but probably slower to run I may guess. I think the LLVM backend could do this but the main code generator I'm not sure.

Regards,
Ryan Joseph

The main concept of pure functions is that they have no side-effects (e.g. don't affect a global state or rely on I/O) and are analogous to a mathematical function.  The main things to draw from it are that for constant inputs, the output is deterministic and can be calculated at compile time (thus replacing the entire call with the result), and for the same inputs, it always produces the same output.

For example, if you have something like: "if (purefunc(X) > Y) and (purefunc(X) < Z) then"... if Z > Y then, even if X is an unknown variable, this can be restructured by the compiler so "purefunc(X)" is only called once (to something akin to "if (purefunc(X) - Y) < (Z - Y) then").

I'm not sure how practical it is for Free Pascal to implement a JIT compiler, but currently there's no support for it.

There is an overhead with pure functions, so you don't really want to mark all functions as pure and let the compiler work it out.

Kit

Op 1-7-2024 om 02:34 schreef Hairy Pixels via fpc-devel:

I had a question about pure functions. I'm seeing some newer languages have a JIT built-in so they can run any function at compile time. To get results at compile time you probably need to use a constant for the parameters but in theory it could read/write to global variables so it's not really "pure" but still makes it possible to run functions at compile time.

FPC has JIT backends like JVM.

Aah, thanks Marco.  I still have some things to learn about FPC!

Kit

But that is just the backend, FPC still works only at compile time, so no JIT at runtime possible. Is it?

Mattias

In the case of JVM, the JIT compiler is specific to Java, I think.  Normally JIT requires the source code to be compiled into an intermediate bytecode first (e.g. Java bytecode or the Common Intermediate Language (.NET)).

Kit

On a related note, I do wonder where pure functions might help with JIT.  It depends on what Florian and the other administrators and developers seek, but currently I aim for my pure function implementation to fulfil both standard properties (1. same output for the same input(s), and 2. no side-effects (usually interpreted as meaning reading from or writing to anything outside of its scope (e.g. global variables))).

Currently, you can define a function as pure and, as long as you don't have anything explicitly impure like a pointer deallocation, the compiler won't know for sure if it is pure or not until you try to call it with a constant parameter - then the compiler checks.  This may cause some issues if the function has a problem like an infinite loop or the result not being set on some branches, and which won't be detected unless you call the pure function with a constant input that triggers the condition.  I'm not sure what the best solution to this is.

Kit

Op 1-7-2024 om 10:33 schreef Mattias Gaertner via fpc-devel:

Hmm, yes. You could maybe interface to the JVM and compile java that way. But I don't even know that is possible, i.e. if every Java VM can actually compile Java (rather than only bytecode), let alone that that wouldn't be FPC code.

Fixed 2 and 3. Thank you. one more ... {\$ifdef FPU_HAS_PURE}pure;{\$ENDIF} FPU_HAS_PURE probably is typo and should be: FPC_HAS_PURE  

Oh yes, that's a silly mistake!  Easy enough to fix hopefully.

Kit

Fixed!  Thanks again Marģers.

Kit