Getting there! I'm having one sticking point, and that's with pure
functions of the following design:
procedure Factorial(N: Cardinal; out R: Cardinal); pure;
begin
if N < 2 then
R := 1
else
begin
Factorial(N - 1, R);
R *= N;
end;
end;
Because of
Fixed my problem with the recursive function (enabling range check and
overflow errors blocked dead-store elimination, so I worked around that)
and the warning no longer cascades. Progress is being made!
Kit
On 16/08/2023 04:02, J. Gareth Moreton via fpc-devel wrote:
So managed to stop the
So managed to stop the cascade in a fairly clean way (it detects the
difference in ErrorCount, marks the call node as erroneous and flags
"codegenerror"), and it seems to work.
pure1a.pp(15,24) Error: Range check error while evaluating constants
(6227020800 must be between -2147483648 and
Hi everyone,
So I'm still working on pure functions and have pushed some merge
requests that are indirectly related to it, mostly simplifying the node
tree so it can more easily be collapsed into simple assignments (what
pure functions should simplify to). Negative testing is still limited,
The field sharing refers to this:
"What I mean is that if a function is marked as "pure" or "inline" (or
both), only one copy of the unoptimised node tree is stored in the
"inlininginfo" field, and both "pass1_pure" and "pass1_inline" duplicate
this tree and transform it as needed. Because
Am 16.12.2022 um 02:02 schrieb J. Gareth Moreton via fpc-devel:
The purity analysis process is very dependent on the node tree being
as clean as possible, and so depends on a fair few merge requests that
have not yet been approved. I'm guessing Florian and Jonas and others
are somewhat busy,
The purity analysis process is very dependent on the node tree being as
clean as possible, and so depends on a fair few merge requests that have
not yet been approved. I'm guessing Florian and Jonas and others are
somewhat busy, what with being December and all.
-
What I mean is that if a function is marked as "pure" or "inline" (or
both), only one copy of the unoptimised node tree is stored in the
"inlininginfo" field, and both "pass1_pure" and "pass1_inline" duplicate
this tree and transform it as needed. Because only the unoptimised tree
is stored,
Am 14.12.2022 um 12:15 schrieb J. Gareth Moreton via fpc-devel:
To better explain how purity analysis currently works (I'm sure
there's a better name than "purity analysis"), it takes a copy of the
unoptimised node tree (this is the same as the tree used for inline,
and for a space saving,
So progress report on converting "Str(constant, output)"... it's not
easy! Firstly, after the first pass, a call node's parameters can get
reordered so they can be placed into ideal registers or on the stack. I
found a workaround for that by adding a new field that records their
original
So it turns out that an "inlinen" node is created initially, but it is
transmuted into a "calln" node by the typecheck pass almost as soon as
it is created. I think the reason it is transmuted so soon is because
differently-named internal procedures have to be called depending on the
input
On 14/12/2022 10:18, Sven Barth via fpc-devel wrote:
Wouldn't it make more sense to ensure that the Str() and Val()
intrinsic work correctly inside "pure" functions? After all the
compiler can then simply evaluate the inlinen nodes and does not
have to "interpret" a ton of
Heh, I had a feeling I was overcomplicating it - thanks Sven. I'll start
experimenting on that one.
On a similar note, my branch has a number of other merge requests
embedded in it, namely the "typeconv-strip" and "nothing-strip" branches
(!232 and !342 respectively) and these are requred to
J. Gareth Moreton via fpc-devel schrieb am
Di., 13. Dez. 2022, 22:09:
> The next big milestone that I want to achieve is to make this a pure
> function:
>
> procedure int_str_unsigned(l:longword;out s:shortstring); pure;
> var
>m1 : longword;
>pcstart,
>pc2start,
>pc,pc2 : pchar;
Fixed that bug! Also fixed a bug where the code analysis would get
upset if you have "X mod Y" behind a "if (Y <> 0) then" check, and Y
evaluates to zero. I've attached a new test project to showcase this
(and which revealed the aforementioned bug). My branch also correctly
replaces the
So there are bugs in my pure function code, specifically with the use of
current_procinfo - I didn't realise until now that the one relating to
the current function is actually freed after the body has been parsed.
Ideally I would have gone the approach of reusing more of the
pass1_inline
The next big milestone that I want to achieve is to make this a pure
function:
procedure int_str_unsigned(l:longword;out s:shortstring); pure;
var
m1 : longword;
pcstart,
pc2start,
pc,pc2 : pchar;
hs : string[32];
overflow : longint;
begin
pc2start:=@s[1];
pc2:=pc2start;
Hi everyone,
I've made a bit of a breakthrough with the development of pure
functions. I've successfully managed to get the compiler to calculate
the factorial as a pure function in two different forms... one usig a
for-loop, and one using a recursive call (which is where it differs from
18 matches
Mail list logo
