This commit fixes a use-after-poison false-positive report from ASAN.
This was due to misuse of SpecificBumpPtrAllocator together with
__asan_poison_memory_region.
The region was poisoned but not deallocated, which caused a the false
positive when trying to destroy and deallocate it in the destructor of
LayoutTypeSystem.
This was fixed by switching to plain BumpPtrAllocator, and properly
calling the Deallocate method, which wraps its own battle-tested ASAN
logic.
Before this commit DLATypeSystem used a
std::set<std::unique_ptr<LayoutTypeSystemNode> to hold nodes, allowing
heterogenous lookup with bare pointers, fast removal being a set,
and providing address stability without requiring an ordering between
LayoutTypeSystemNodes.
The same requirements is now obtained more cleanly using with a
BumpPtrAllocator for nodes, and a set of naked pointers to them to
enable fast lookup and removal.
They have been substituted with `print` methods, that are more general.
The `dumpToString` is emitted automatically with a template in a revng
header, for those classes that already have the `print` method anyway.
This is a utility class useful to make std::set<std::unique_ptr<T>>
searchable with raw pointers, by using
std::set<std::unique_ptr<T>, HeterogeneousPtrCompare<T>> instead.
This is a flag used to mark a given `LayoutTypeSystemNode`.
It represents the fact that the children nodes are either all
interfering with each other, non-interfering with each other, or
unknown.
This information will be filled-in by the
`ComputeNonInterferingComponents` step, and will be used from the
`MakeLayouts` step to decide if the children of the node will be emitted
as fields of a union (interfering) or fields of a struct
(non-interfering).
This method allows to create artificial layouts that are not directly
associated to `llvm::Value`s.
Because of this missing association with `Value`s, the artificial
layouts are not retrievable by using the public `getOrCreateLayoutType`
and `getLayoutType` methods of `LayoutTypeSystem`, but they will be
accessible only by walking the graph.
The capability to add layouts that are not associated to `llvm::Value`s
is necessary for the future implementation of the DLA Step:
`ComputeNonInterferingComponents`.
The step will add artificial layouts to represent non-intefering
components.