Looking to contribute/help

[Hels15]

Hey, we just finished Chapter 21 in Simple, so if you need help porting any of that stuff, I’d be happy to help out. I checked out the notes you made—they look really cool. I’d be glad to work on a few of the implementations (like the different IR types) and help write up the docs for them.

Are you still using Discord for communication? Or should I reach out via email?

[dibyendumajumdar]

Hey @Hels15

Your contributions would be very welcome!
Maybe this is a good place to discuss, I find Discord is like a private club so I have stopped using it.

[dibyendumajumdar]

I have not read it - but this may help?

https://craftinginterpreters.com/contents.html#a-bytecode-virtual-machine

[Hels15]

@dibyendumajumdar I'm also interested to know if the optimisation in: https://github.com/CompilerProgramming/ez-lang/blob/main/optvm/src/main/java/com/compilerprogramming/ezlang/compiler/Liveness.java is something specific to SSA-cfg compilers as opposed to SoN or maybe we have something similar in Simple? Like I don't know if it is a completely different thing from what we have in Simple(thus SoN) or no. I'm still in the process of examining your project.

[dibyendumajumdar]

Hi, the optimizations in optvm project are for compilers that use traditional SSA rather than the Sea of Nodes. In the SON approach we don't calculate liveness separately, as its kind of part of the process of compiling. If a Node has no users then it is dropped; and this happens recursively. Although in Simple, we have to at times fool the compiler into thinking something is live as otherwise it might drop a node that is still needed.

[Hels15]

Why is it not possible to maintain the SSA edges(use-def chains) - I would think that even traditional CFG-SSA IR could use that for liveness analysis?

[dibyendumajumdar]

Currently the def-use chains are only suitable for SSA - i.e. a single definition is expected. If the IR is pre-SSA then this is not the case, we would need extended def-use chains that allow for multiple definitions - we need this when we start to look at non-SSA data flow analyses.

Of course all def use chains can be maintained as we make changes to the IR - both pre and post SSA. I didn't do it this way as it is purely an optimization, and first I wanted to get the implementation 100% correct before looking at ways to optimize. But also the optimizations make code harder to follow, so ideally we want those to be optional.