Performance

[mhyee]

• TypedAst -> A Normal Form IR
• CodeGen for Integer expressions.
• CodeGen for functions.
• CodeGen for rules.
• Integer representation of values.

[magnus-madsen]

The new plan is not to do A normal form, since the JVM bytecode is stack based, and that is easier to generate straight from an AST.

I am going to be creating and moving some more complete programs, to experiment on, into the examples/domains/ folder.

These should make for good compilation targets.

[magnus-madsen]

I want to give a few pointers on what I think is important for the CodeGen:

1. Attach debug information (e.g. filename, line no, col no) to generated class(es). This will be immensely useful for debugging and profiling.
2. Don't worry about the performance of the CodeGenerator. Use all available help facilities from ASM5. This includes letting it calculate max variables and frames, but also running with all the checkers.
3. Focus on generating the code. We will figure out how to execute it later. Probably we will decorate one of our ASTs with references to the code loaded via reflection. You should still be able to write tests though. Just write a simple wrapper around a class loader.
4. If longs are too troublesome, then you can start with Ints. I will leave this choice to you. Ultimately we probably have Longs, or both Int and Longs.
5. Use the CodeGenIR AST and modified it to have what you need. Once you have a reasonable implementation, we can write a simple translation from TypedAst to it. (For a subset of expressions at first).

Less important, but "nice-to-have" in the future:

1. Instead of generating one class with names like Belnap$Leq, we should map the Flix namespaces to Java packages, so A::B::C::Leq would create packages A and B, with class C and method Leq on C.

[magnus-madsen]

Oh, and I forgot, and this is important:

Make sure the CodeGen is functional. Thus, I think it is better to explicitly pass around the Class/Method visitors. Unless you see a strong reason not to.

[mhyee]

Don't worry about the performance of the CodeGenerator. Use all available help facilities from ASM5. This includes letting it calculate max variables and frames, but also running with all the checkers.

I'll need to look into this (maybe later), but it seems that the stack and frame computation runs after the CheckClassAdapter. So I have to put large bogus numbers (and hope they're large enough) to ensure the CheckClassAdapter doesn't crash. These bogus numbers are then overwritten by the actual numbers.

Make sure the CodeGen is functional. Thus, I think it is better to explicitly pass around the Class/Method visitors. Unless you see a strong reason not to.

I don't see a reason not to, but I'm curious, what's the reason for explicitly passing the visitors around?

[magnus-madsen]

I don't see a reason not to, but I'm curious, what's the reason for explicitly passing the visitors around?

Mostly to ensure that Flix can be instantiated multiple times in the same JVM, and in the future to ensure that we can even run the same Flix instance in parallel. Thus staying as close as possible to functional programming is preferable.

[magnus-madsen]

I think we will have the following (backend) IRs:

• SimplifiedIR - The TypedAst with match, switch, and other high-level constructs eliminated. Variables are numbered etc.
• ReducedIR - The SimplifiedIR with partial evaluation applied. E.g. constant expressions are folded. Functions may be inlined, etc. The compiler will generate code from this IR.
• ExecutableIR - The only mutable AST/IR. Decorated with the code generator from the compiler. (We can make it so that if a function was not compiled, then it is interpreted. I think that would be nice). This IR uses arrays, mutable var's that hold references to IndexedRelation and IndexedStore. Rules may hold mutable cost and queries plans, etc. etc. The same ExecutableIR cannot be evaluated twice.

[magnus-madsen]

(Note to self: Where are the data types packed? In the ReducedIR or in a separate IR?)

[magnus-madsen]

I think we can get rid of ReducedIR. At least for now. Instead we should just merge ReducedIR and SimplifiedIR into one thing.

We will still have ExecutableIR though, which should be the output of the CodeGen phase.

Lets make this change together.

[mhyee]

Closing this and opening fine-grained issues instead.