mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2026-01-31 01:35:20 +01:00
166ce9a607
When it was first created, CFGSort only made sure BBs in each
`MachineLoop` are sorted together. After we added exception support,
CFGSort now also sorts BBs in each `WebAssemblyException`, which
represents a `catch` block, together, and
`Region` class was introduced to be a thin wrapper for both
`MachineLoop` and `WebAssemblyException`.
But how we compute those loops and exceptions is different.
`MachineLoopInfo` is constructed using the standard loop computation
algorithm in LLVM; the definition of loop is "a set of BBs that are
dominated by a loop header and have a path back to the loop header". So
even if some BBs are semantically contained by a loop in the original
program, or in other words dominated by a loop header, if they don't
have a path back to the loop header, they are not considered a part of
the loop. For example, if a BB is dominated by a loop header but
contains `call abort()` or `rethrow`, it wouldn't have a path back to
the header, so it is not included in the loop.
But `WebAssemblyException` is wasm-specific data structure, and its
algorithm is simple: a `WebAssemblyException` consists of an EH pad and
all BBs dominated by the EH pad. So this scenario is possible: (This is
also the situation in the newly added test in cfg-stackify-eh.ll)
```
Loop L: header, A, ehpad, latch
Exception E: ehpad, latch, B
```
(B contains `abort()`, so it does not have a path back to the loop
header, so it is not included in L.)
And it is sorted in this order:
```
header
A
ehpad
latch
B
```
And when CFGStackify places `end_loop` or `end_try` markers, it
previously used `WebAssembly::getBottom()`, which returns the latest BB
in the sorted order, and placed the marker there. So in this case the
marker placements will be like this:
```
loop
header
try
A
catch
ehpad
latch
end_loop <-- misplaced!
B
end_try
```
in which nesting between the loop and the exception is not correct.
`end_loop` marker has to be placed after `B`, and also after `end_try`.
Maybe the fundamental way to solve this problem is to come up with our
own algorithm for computing loop region too, in which we include all BBs
dominated by a loop header in a loop. But this takes a lot more effort.
The only thing we need to fix is actually, `getBottom()`. If we make it
return the right BB, which means in case of a loop, the latest BB of the
loop itself and all exceptions contained in there, we are good.
This renames `Region` and `RegionInfo` to `SortRegion` and
`SortRegionInfo` and extracts them into their own file. And add
`getBottom` to `SortRegionInfo` class, from which it can access
`WebAssemblyExceptionInfo`, so that it can compute a correct bottom
block for loops.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D84724
74 lines
2.8 KiB
C++
74 lines
2.8 KiB
C++
#include "WebAssemblySortRegion.h"
|
|
#include "WebAssemblyExceptionInfo.h"
|
|
#include "llvm/CodeGen/MachineLoopInfo.h"
|
|
|
|
using namespace llvm;
|
|
using namespace WebAssembly;
|
|
|
|
template <> bool ConcreteSortRegion<MachineLoop>::isLoop() const {
|
|
return true;
|
|
}
|
|
|
|
const SortRegion *SortRegionInfo::getRegionFor(const MachineBasicBlock *MBB) {
|
|
const auto *ML = MLI.getLoopFor(MBB);
|
|
const auto *WE = WEI.getExceptionFor(MBB);
|
|
if (!ML && !WE)
|
|
return nullptr;
|
|
// We determine subregion relationship by domination of their headers, i.e.,
|
|
// if region A's header dominates region B's header, B is a subregion of A.
|
|
// WebAssemblyException contains BBs in all its subregions (loops or
|
|
// exceptions), but MachineLoop may not, because MachineLoop does not
|
|
// contain BBs that don't have a path to its header even if they are
|
|
// dominated by its header. So here we should use
|
|
// WE->contains(ML->getHeader()), but not ML->contains(WE->getHeader()).
|
|
if ((ML && !WE) || (ML && WE && WE->contains(ML->getHeader()))) {
|
|
// If the smallest region containing MBB is a loop
|
|
if (LoopMap.count(ML))
|
|
return LoopMap[ML].get();
|
|
LoopMap[ML] = std::make_unique<ConcreteSortRegion<MachineLoop>>(ML);
|
|
return LoopMap[ML].get();
|
|
} else {
|
|
// If the smallest region containing MBB is an exception
|
|
if (ExceptionMap.count(WE))
|
|
return ExceptionMap[WE].get();
|
|
ExceptionMap[WE] =
|
|
std::make_unique<ConcreteSortRegion<WebAssemblyException>>(WE);
|
|
return ExceptionMap[WE].get();
|
|
}
|
|
}
|
|
|
|
MachineBasicBlock *SortRegionInfo::getBottom(const SortRegion *R) {
|
|
if (R->isLoop())
|
|
return getBottom(MLI.getLoopFor(R->getHeader()));
|
|
else
|
|
return getBottom(WEI.getExceptionFor(R->getHeader()));
|
|
}
|
|
|
|
MachineBasicBlock *SortRegionInfo::getBottom(const MachineLoop *ML) {
|
|
MachineBasicBlock *Bottom = ML->getHeader();
|
|
for (MachineBasicBlock *MBB : ML->blocks()) {
|
|
if (MBB->getNumber() > Bottom->getNumber())
|
|
Bottom = MBB;
|
|
// MachineLoop does not contain all BBs dominated by its header. BBs that
|
|
// don't have a path back to the loop header aren't included. But for the
|
|
// purpose of CFG sorting and stackification, we need a bottom BB among all
|
|
// BBs that are dominated by the loop header. So we check if there is any
|
|
// WebAssemblyException contained in this loop, and computes the most bottom
|
|
// BB of them all.
|
|
if (MBB->isEHPad()) {
|
|
MachineBasicBlock *ExBottom = getBottom(WEI.getExceptionFor(MBB));
|
|
if (ExBottom->getNumber() > Bottom->getNumber())
|
|
Bottom = ExBottom;
|
|
}
|
|
}
|
|
return Bottom;
|
|
}
|
|
|
|
MachineBasicBlock *SortRegionInfo::getBottom(const WebAssemblyException *WE) {
|
|
MachineBasicBlock *Bottom = WE->getHeader();
|
|
for (MachineBasicBlock *MBB : WE->blocks())
|
|
if (MBB->getNumber() > Bottom->getNumber())
|
|
Bottom = MBB;
|
|
return Bottom;
|
|
}
|