FunctionMetadata was being deserialized every time they were
inspected. This commit introduces a cache structure to prevent this
excessive deserializations.
Instruction definition tags are now generated as a 0-size anchor on
the LHS of the text of the actual instruction, this is to prevent
a potential user asking for the definition/reference of the single
instruction.
Use model::Function::Key for the Function rank instead of the naked
MetaAddress as it allows forward-compatibility if the model::Function
key is ever changed.
Use a std::tuple<uint64_t> for TypeField as it's the current type for
{Struct,Enum,Union}Field.key()
Having the initial rank threshhold too low caused them to sometimes
loop around and become negative, causing problems later down the line.
This sets the rank of the "entry" node to 4 offsetting the possible
causes of this issue quite a bit.
(the following is the original commit message)
The last step is pretty simple. All that's left to do is to take the
ordered edge container and to `append` their points to their `Path`
(the following is the original commit message)
Now that the problematic edges are dealt with, all the normal edges
need to also get routed, but first, it's a good idea to order them.
As such, the DAG is consumed to produce the list of all the edges in
the optimal order for them to get routed.
(the following is the original commit message)
Now that every single node has gotten its exact position, the only
thing left to do is to route all the edges between them. First of
all, the special edges (like corners) need to be handled.
(the following is the original commit message)
Now, that it's precisely known how much space is needed between each
pair of the layers, it's possible to set the vertical coordinates for
each of the nodes based on the layer heights (the height of the
longest node within said layer) and the number of horizontal lanes
required after it.
(the following is the original commit message)
Now that the nodes are placed into the grid (at least horizontally),
it's possible to focus on the edges. Since, the information about
the number of edges going from/to each of the layers is known, it's
possible to determine the number of horizontal space needed to placed
those.
In this part of the layouter, the focus is on three different laning
points:
- horizontal lanes between layers.
- entry lanes for each of the nodes.
- exit lanes for each of the nodes.
Indexation is done independently for each of the lane types.
(the following is the original commit message)
Since the predetermined order of the nodes for each layer was already
predetermined, what's left is to put their coordinates based on the
size of the nodes and the predefined margins between them.
Except the resulting layouts are extremely left-heavy. As such, it's
important to use the coordinate selection part to push as many nodes
to the right as possible to balance the graph out at least somewhat.
Massimo Fioravanti