Code generation #5

New Issue

pca006132 · 2021-07-29T17:01:46+08:00

pca006132 commented

2021-07-29 17:01:46 +08:00

The code generation task would be distributed to several worker threads, each maintaining an LLVM context for code generation. Worker threads would share a mapping from function instances to symbol names to track instantiated functions. Function instances that were not generated previously would be pushed to a work queue, and the worker threads would fetch tasks from the work queue. Note that the mapping may be associated with each function/methods instead of a giant map.

The name mangling scheme is not yet decided. The simplest way would be to add a unique integer to each instantiation of the same function. This should be fine as we compile all modules at once, and we have a mapping to keep track of the names.

Using worker threads explicitly could allow us to reuse the LLVM context.
Each thread would require its LLVM context, and it needs to create the types in the context, which may be inefficient if we repeat this for every function instance.

Worker threads would share the class definitions. The order of the fields in the memory layout is the same as the declaration order in nac3. Inheritance is implemented by concatenating the fields of an object. Worker threads would add a type definition to its LLVM context when it is being used in the function body for the first time (in the worker thread).

The constructs would be mapped to IR according to this guide: https://mapping-high-level-constructs-to-llvm-ir.readthedocs.io/en/latest/README.html

The code generation task would be distributed to several worker threads, each maintaining an LLVM context for code generation. Worker threads would share a mapping from function instances to symbol names to track instantiated functions. Function instances that were not generated previously would be pushed to a work queue, and the worker threads would fetch tasks from the work queue. Note that the mapping may be associated with each function/methods instead of a giant map. The name mangling scheme is not yet decided. The simplest way would be to add a unique integer to each instantiation of the same function. This should be fine as we compile all modules at once, and we have a mapping to keep track of the names. Using worker threads explicitly could allow us to reuse the LLVM context. Each thread would require its LLVM context, and it needs to create the types in the context, which may be inefficient if we repeat this for every function instance. Worker threads would share the class definitions. The order of the fields in the memory layout is the same as the declaration order in nac3. Inheritance is implemented by concatenating the fields of an object. Worker threads would add a type definition to its LLVM context when it is being used in the function body for the first time (in the worker thread). The constructs would be mapped to IR according to this guide: https://mapping-high-level-constructs-to-llvm-ir.readthedocs.io/en/latest/README.html

sb10q commented

2021-09-29 08:56:23 +08:00

Can we close this issue? Seems code generation is done generally and we could move to more specific issues.

pca006132 closed this issue

2021-09-29 09:11:37 +08:00

Sign in to join this conversation.