<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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 right-to-left ordering. Despite the
headache, I managed to consistently change it to an assignment of
a string literal to the output variable. Success, right? Wrong!
The first pass converts such an assignment to another call node!</p>
<p><font face="monospace"><calln resultdef="$void" pos="12,3"
flags="nf_pass1_done" complexity="255"><br>
<procname>$fpc_shortstr_to_shortstr(out
OpenString;<const Int64>;const
ShortString);</procname><br>
<callparan resultdef="ShortString" pos="12,3"><br>
<stringconstn resultdef="ShortString" pos="12,3"
flags="nf_pass1_done" complexity="1"><br>
<stringtype>shortstring</stringtype><br>
<length>1</length><br>
<value>5</value><br>
</stringconstn><br>
</callparan><br>
<callparan resultdef="OpenString" pos="12,3"><br>
<loadn resultdef="ShortString" pos="12,3"
flags="nf_pass1_done,nf_write" complexity="1"><br>
<symbol>OUTPUT</symbol><br>
</loadn><br>
</callparan><br>
<callparan resultdef="Int64" pos="12,3"><br>
<ordconstn resultdef="Int64" pos="12,3"
flags="nf_pass1_done,nf_explicit" complexity="0"
rangecheck="TRUE"><br>
<value>255</value><br>
</ordconstn><br>
</callparan><br>
</calln></font><br>
</p>
<p>(The third "255" parameter seems to be some kind of encoding
parameter)<br>
</p>
<p>Here, the original line of code was "Str(5, Output);". This is
actually pretty difficult to solve.</p>
<p>It might be that I have to find a way to perform purity analysis
without ever calling firstpass on the node tree, which is
currently needed for processing nested pure and inline
functions... granted, I can possibly do that selectively using
"foreachnode" or "foreachnodestatic".<br>
</p>
<p>Kit<br>
</p>
<div class="moz-cite-prefix">On 14/12/2022 12:21, J. Gareth Moreton
via fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2f312a5a-20fc-1a12-751c-381c00391374@moreton-family.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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 moz-txt-link-freetext" href="mailto:fpc-devel@lists.freepascal.org" moz-do-not-send="true">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" moz-do-not-send="true">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
<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>