<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 14/12/2022 10:18, Sven Barth via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFMUeB-2dX7rAJj6Kh+rnaeM_cfH+OHRxZkf6QQRXaboiAOGRw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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 other code
as well.</blockquote>
</div>
</div>
</div>
</blockquote>
<p>So I just tried a simple test with "System.Str(5, Output);" (with
Output defined as a string), and it produced the following nodes:</p>
<p><font face="monospace"><calln resultdef="$void" pos="12,3"><br>
...<procname>$fpc_shortstr_sint(Int64;Int64;out
OpenString;<const Int64>);</procname><br>
...<callparan resultdef="Int64" pos="12,3"><br>
......<ordconstn resultdef="Int64" pos="12,3"
flags="nf_explicit" rangecheck="TRUE"><br>
.........<value>255</value><br>
......</ordconstn><br>
...</callparan><br>
...<callparan resultdef="OpenString" pos="12,23"><br>
......<loadn resultdef="ShortString" pos="12,23"
flags="nf_write"><br>
.........<symbol>OUTPUT</symbol><br>
......</loadn><br>
...</callparan><br>
...<callparan resultdef="Int64" pos="12,3"><br>
......<ordconstn resultdef="Int64" pos="12,3"
rangecheck="FALSE"><br>
.........<value>-1</value><br>
......</ordconstn><br>
...</callparan><br>
...<callparan resultdef="Int64" pos="12,15"><br>
......<ordconstn resultdef="Int64" pos="12,15"
rangecheck="FALSE"><br>
.........<value>5</value><br>
......</ordconstn><br>
...</callparan><br>
</calln></font></p>
<p>This is before the first pass, so the parser immediately replaces
it with a call to the internal compiler procedure.</p>
<p>How should I handle this? There are a few problems I need to
consider. If I use a new kind of inline node that expands into a
regular call after the first pass, I'll still need to handle the
case where it is a call node because there are situations during
purity analysis where nested pure functions are not analysed
because their actual parameters haven't yet been fully calculated
(usually requires another found of constant propagation and inline
simplification). It may be that I need to add some kind of field
to the TCallNode to indicate which internal function it's
referring to.</p>
<p>I'll try to do a new merge request soon so Str and Val can be
simplified at the node level, as this can easily have benefits
outside of pure functions.<br>
</p>
<p>Kit<br>
</p>
</body>
</html>