[fpc-devel] Progress on pure functions

[J. Gareth Moreton]

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.

Kit

On 14/12/2022 11:39, J. Gareth Moreton via fpc-devel wrote:
>
>
> 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 other code as well.
>>
> So I just tried a simple test with "System.Str(5, Output);" (with 
> Output defined as a string), and it produced the following nodes:
>
> <calln resultdef="$void" pos="12,3">
> ...<procname>$fpc_shortstr_sint(Int64;Int64;out OpenString;<const 
> Int64>);</procname>
> ...<callparan resultdef="Int64" pos="12,3">
> ......<ordconstn resultdef="Int64" pos="12,3" flags="nf_explicit" 
> rangecheck="TRUE">
> .........<value>255</value>
> ......</ordconstn>
> ...</callparan>
> ...<callparan resultdef="OpenString" pos="12,23">
> ......<loadn resultdef="ShortString" pos="12,23" flags="nf_write">
> .........<symbol>OUTPUT</symbol>
> ......</loadn>
> ...</callparan>
> ...<callparan resultdef="Int64" pos="12,3">
> ......<ordconstn resultdef="Int64" pos="12,3" rangecheck="FALSE">
> .........<value>-1</value>
> ......</ordconstn>
> ...</callparan>
> ...<callparan resultdef="Int64" pos="12,15">
> ......<ordconstn resultdef="Int64" pos="12,15" rangecheck="FALSE">
> .........<value>5</value>
> ......</ordconstn>
> ...</callparan>
> </calln>
>
> This is before the first pass, so the parser immediately replaces it 
> with a call to the internal compiler procedure.
>
> 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.
>
> 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.
>
> Kit
>
>
> _______________________________________________
> fpc-devel maillist  -fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20221214/4d5e22a7/attachment-0001.htm>