The `Head` election now works in a bottom-up fashion (child regions are
processed before the parent ones), and ensures that the `Head` election
process is coherent across multiple nested regions.
This means that:
1) The late entries are coherent between the nested regions. If a node
is selected as a late entry for a region, the parent region must
follow this decision too.
2) If a node which is a `Head` candidate for a parent region, is
selected as the `Head` for a child region, the same choice must be
performed for the parent region too.
During the `Head` election phase, we now introduce the following
additional criterion:
When processing a `GenericRegion` nested into an outer one (its
`ParentRegion`), if the inner `Region` contains the block that has been
elected as `Head` of the `ParentRegion`, we also force that block to be
the `Head` of the inner `GenericRegion`.
We add a unit test to check this behavior.
Add the needed support for running `GenericRegionInfo` on the
`ScopeGraph`.
This needs a new ad-hoc `getGenericCycleInfo` helper in order to unwrap
the `Graph` object (pointing to the underlying `Function *`) from the
`Scope` wrapper object.
We implement the `GenericRegionInfo` analysis.
The analysis accepts a template parameter which enables to run it on
every graph which exposes `llvm::GraphTraits`.
The `GenericRegionPass` is responsible for instantiating and running the
analysis on a `llvm::Function`.
The `GenericRegionInfo` analysis uses, and takes insipiration from the
`GenericCycleInfo` LLVM analysis.
The analysis exposes a tree of well nested `GenericRegion`s, which are
constructed starting from the well nested tree of `GenericCycle`s.
In addition, we perform the election of the `Head` of each
`GenericRegion`, and the election of the retreating edges.
Andrea Gussoni