This commit introduces new tags to specify how LLVMContainer should
deduplicate sets of equivalent functions, typically managed by an
`OpaqueFunctionPool`.
This method enables pipes to specify a custom invalidation logic. This
change enables us to supress automatic model tracking in certain parts
and then handle the consequences by hand.
Make sure you read the TODO before using this.
This comit propagates the deduced info about inputs and outputs of pipes
all the way up to the runner, so that the requested output of a pipe can
be passed to its invocation.
Implement the pruning of container caches (resume directory) when there
is a mismatch between the current revng components' hash and the saved
one. This functionality is activated via `-check-components-version`.
The invalidation map passed by callers of pipeline invalidate was
assumed to be always empty. This requirement has been relaxed.
The pipe invalidation cache now checks that what must be removed is
actually present. This is relevant for targets that are killed by later
pipes before the end of the step.
Replace the stub implementation of invalidation with the proper
implementation. A ReadPathCache is added to each global so that it can
keep tracks of what target are associated to which read paths.
Add the PipelineDescription object that describes the structure of a
pipeline. This will be used by all the downstream users instead of
pipeline accessor methods via PipelineC.
This commit changes the following method names across the codebase:
* `storeToDisk` -> `store`
* `loadFromDisk` -> `load`
This has been done since the storage is no longer bound to the local
storage.
This commit introduces the concept of `Component` to a pipeline step.
This, in turn, can be used by clients to figure out which artifacts are
produced by which revng component.
Additionally, this commit overhauls the `revng daemon-self-test`
command, renaming it to `revng graphql` and adding extra flexibility.
This commit forces verification of the loaded `llvm::Module`, since
`llvm::parseIR` does not do it.
It also improves reporting parsing errors while loading the module.
Many Pipeline objects (Globals, Ranks, Kinds, Targets in a TargetList)
were ordered by load order, this makes the playback of traces difficult.
Moreover the order of loading of pipeline files also influences the
ordering of other elements (Step, Analys{is,esLists}). These are also
ordered to prevent incosistent ordering.
Alessandro Di Federico