You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: