[Proposal] Code restructure

[ruvi-d]

Purpose

1. To fix remaining memory leaks due to cyclic sharing of smart pointers
2. To make multi-threaded compiling possible
3. Improve maintainability

Proposal

Restructure the codegen logic using the visitor pattern

• This would decouple the codegen logic from the individual BIR model classes and move them to new visitor classes
• These new visitor classes will hold all the generated LLVM values, references, etc that are currently part of the BIR model classes
• Thus the BIR model classes will be const after creation

Dependency inversion

• The D in SOILD deign principles
• E.g. instead of having basic blocks consist of a container of instructions and each instruction having a reference back to it's parent basic block; the basic block will no longer contain it's instructions
• Instead, all instructions from all the basic blocks will be in one container
• This applies to all other levels as well. .i.e all basic blocks from all functions in one container; all functions from all packages in on container.. etc
  • There is some scope to further improve performance by having different containers for different sub classes; thus allowing us to avoid runtime polymorphism via v-tables
  • This approach should also help improve memory and instruction locality
• The end result is that the output of the BIR parser will be a flat struct of containers; as opposed to the single Package class that is currently being generated, with it's multiple level's of associated classes.

Codegen modeled as data transformations

• The idea is to model codegen as multiple transformations (function calls on input data) that is done to the BIR model class objects created from parsing the BIR dump
  • i.e a very data oriented design approach
• The aforementioned containers of BIR class objects will be processed one by one; starting from the top level packages down to the low level instructions
• At each level we can potentially parallel transform the objects in a container, e.g. process all the local variables from all the functions in parallel

Notes

• This rather large restructuring  is not a must to address the the memory leak issue
  • That problem can potentially be solved by replacing some of the shared pointer to parent objects with object references
• But I think this will be a must to support efficient multi threaded code generation
• The dependency inversion and transformation passes model changes should also make the code base easier to maintain in the long run (i.e. easier to extend, write tests, etc..)

[ruvi-d]

@ayonam appreciate your input

[ruvi-d]

Many of the mentioned suggestions have been implemented with #282