Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a LIR format. #29

Open
nbp opened this issue Aug 18, 2018 · 0 comments
Open

Add a LIR format. #29

nbp opened this issue Aug 18, 2018 · 0 comments
Assignees

Comments

@nbp
Copy link
Owner

nbp commented Aug 18, 2018

The current IR is a quick and dirty format made only to support the needs of a proof of concept than something which deserve to remain as-is in the next version.

However, one concept might still be interesting to investigate, such as having SSA values which sizes are not restricted to simple types, and being able to address memory inside them. Thus we could have SSA values which are representing complex data structures, and the need of addressing in them could force them to be stack allocated.

One of the feature that needs to be added, and is not yet tried in any JIT as far as I know, it to version parts of the data flow graph and control flow graph, in order to make the graph patchable (literally applying patches in a version control system). Among the required features to be able to frequently apply previously recorded patches — graph mutation made during previous compilations — to a graph, we need the nodes (instructions) of the graph to have a limited context. Thus, having a little as possible ordering edges and no indexes. (Should this be named VSSA for Versioned SSA?)

The usual control flow represenation approach of SSA, made out of basic blocks, which forces the order of all instructions from the beginning might cause the patches to not be applicable because of newly inserted nodes. The sea-of-nodes representation would remove the ordering of instructions until the scheduling pass, which would help.

Also, SSA relies on the indexing of instructions, in order to access them quickly. For a VSSA, we have to add a way to index instruction which is stable across multiple compilations. A content-addressing will cause the data-flow of an instruction to be replaced each time an instruction is mutated, which is too much. However, we can have a content-addressing which ignores a replaced_by field which can be mutated (patched) and record the content-address of the newer instruction.

@nbp nbp added this to the v0.1.0: Cranelift + LIR milestone Aug 18, 2018
@nbp nbp self-assigned this Aug 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant