<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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 types. I think the easiest way I
can handle this is to add a new optional field to indicate which
class of internal functions the node was generated from, and
pass_1 can perform unique processing on it if certain criteria are
met... and if they are not met, or the field is set to a value the
compiler doesn't recognise, it just falls back to regular
call-node handling.</p>
<p>Kit<br>
</p>
<div class="moz-cite-prefix">On 14/12/2022 11:39, J. Gareth Moreton
via fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:993d3840-beee-cf2a-4b82-82db5a547a9d@moreton-family.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
fpc-devel maillist - <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
</body>
</html>