Re: GSoC compiler work, SICL

Hi Bruno, Sam,

> Re 3: clisp's LOOP has a number of optimizations already in the macro.
> It is possible that cleavir adds more optimizations to it, but this would
> not be the major benefit.
By 'loop optimizations', I meant more flow-graph analytic
optimizations, eg. using dominance information on the instruction
graph. Perhaps clisp already does these sorts of optimizations as well
at a higher level. This would fall into the general category of flow
sensitive optimizations, which I envision would be an ambitious but
important part of the SICL integration.

> This is good; however, we should still strive to define the functionality
> of the deliverables. For example, pick the right ones among these:
>   - Make the SICL compiler core run in clisp.
>   - Connect it to the clisp LAP assembler as backend, so that it can be
>     used to create compiled clisp functions.
I agree that getting the SICL compiler core running in clisp would be
the main deliverable; after all, that would be the prerequisite for
adding anything else from Cleavir.

>   - Make the COMPILE function work flawlessly in all cases.
>   - Make the DISASSEMBLE function work flawlessly in all cases.
>   - Make the COMPILE-FILE function work flawlessly in all cases.
>     This implies proper handling of LOAD-TIME-VALUE.

I am not too sure what you mean here. I think that SICL would be
integrated at a level high enough where this would not impact the
bytecode emitter/dissassembler, and hence not disrupt DISASSEMBLE, etc
too much. As you say, once Cleavir is connected to the LAP side of
things, it should be emitting the already existing clisp bytecode.
There are SSA-form and Register-Allocation modules as well in SICL
that work at a lower level, but I think this may be stretching the
scope of the project. In other words, it seems like it is possible to
add all the necessary machinery to support dataflow analysis from SICL
within the existing framework of the clisp bytecode and FASL formats.

>> Calling closures always conses (by calling copy-closure).
>> Can this be eliminated?
>> ...
>> > Scheme-like optimizations.
>>
>> What is that?
>
> This is what I meant. Based on data-flow analysis, the compiler may determine
> that a local function is only used within the dynamic extent of the function
> that defines it. Which means that the closure can be stack-allocated - no
> consing.
I believe SICL has already produced an escape analysis module which is
being actively developed and used with clasp. So yes - better dynamic
extent allocation in general and non-consing closures specifically
would be another possible deliverable. I think it would actually be
much harder to implement general escape analyses without a general
flow graph structure, so getting SICL in might be the 'right' way to
do this.

> Yes, I am willing to mentor you with this kind of project.
Great, I'll be discussing with the SICL people and start fleshing out
a proposal to be submitted by next week.

Thanks,
Charles


On Wed, Mar 21, 2018 at 3:50 PM, Bruno Haible <[email protected]> wrote:
> Sam wrote:
>
>> I think better handling of local functions in general would be a good
>> improvement and a sizable project.
>
> Yes. Note that this can go into different directions:
>   - Compiling local functions in a better way requires data-flow analysis;
>     this would be one outcome of the SICL work.
>   - Making local functions more debuggable, on the other hand, goes in the
>     opposite direction, as it prevents some optimizations. In my opinion,
>     this is much less work than a GSoC project (only ca. 2-4 weeks).
>
>> Calling closures always conses (by calling copy-closure).
>> Can this be eliminated?
>> ...
>> > Scheme-like optimizations.
>>
>> What is that?
>
> This is what I meant. Based on data-flow analysis, the compiler may determine
> that a local function is only used within the dynamic extent of the function
> that defines it. Which means that the closure can be stack-allocated - no
> consing.
>
> There are surely more optimizations that a good Scheme compiler does, that
> would apply in clisp as well.
>
> Bruno
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> clisp-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/clisp-devel



-- 
Class of 2021

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel