llvm-project/llvm/lib/Target/WebAssembly/WebAssemblySortRegion.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

92 lines
3.0 KiB
C
Raw Normal View History

[WebAssembly] Fix getBottom for loops 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
2020-07-29 16:19:36 +08:00
//===-- WebAssemblySortRegion.h - WebAssembly Sort SortRegion ----*- C++-*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
///
/// \file
/// \brief This file implements regions used in CFGSort and CFGStackify.
///
//===----------------------------------------------------------------------===//
#ifndef LLVM_LIB_TARGET_WEBASSEMBLY_WEBASSEMBLYSORTREGION_H
#define LLVM_LIB_TARGET_WEBASSEMBLY_WEBASSEMBLYSORTREGION_H
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/DenseMap.h"
#include "llvm/ADT/iterator_range.h"
namespace llvm {
class MachineBasicBlock;
class MachineLoop;
class MachineLoopInfo;
class WebAssemblyException;
class WebAssemblyExceptionInfo;
namespace WebAssembly {
// Wrapper for loops and exceptions
class SortRegion {
public:
virtual ~SortRegion() = default;
virtual MachineBasicBlock *getHeader() const = 0;
virtual bool contains(const MachineBasicBlock *MBB) const = 0;
virtual unsigned getNumBlocks() const = 0;
using block_iterator = typename ArrayRef<MachineBasicBlock *>::const_iterator;
virtual iterator_range<block_iterator> blocks() const = 0;
virtual bool isLoop() const = 0;
};
template <typename T> class ConcreteSortRegion : public SortRegion {
const T *Unit;
public:
ConcreteSortRegion(const T *Unit) : Unit(Unit) {}
MachineBasicBlock *getHeader() const override { return Unit->getHeader(); }
bool contains(const MachineBasicBlock *MBB) const override {
return Unit->contains(MBB);
}
unsigned getNumBlocks() const override { return Unit->getNumBlocks(); }
iterator_range<block_iterator> blocks() const override {
return Unit->blocks();
}
bool isLoop() const override { return false; }
};
// This class has information of nested SortRegions; this is analogous to what
// LoopInfo is for loops.
class SortRegionInfo {
friend class ConcreteSortRegion<MachineLoopInfo>;
friend class ConcreteSortRegion<WebAssemblyException>;
const MachineLoopInfo &MLI;
const WebAssemblyExceptionInfo &WEI;
DenseMap<const MachineLoop *, std::unique_ptr<SortRegion>> LoopMap;
DenseMap<const WebAssemblyException *, std::unique_ptr<SortRegion>>
ExceptionMap;
public:
SortRegionInfo(const MachineLoopInfo &MLI,
const WebAssemblyExceptionInfo &WEI)
: MLI(MLI), WEI(WEI) {}
// Returns a smallest loop or exception that contains MBB
const SortRegion *getRegionFor(const MachineBasicBlock *MBB);
// Return the "bottom" block among all blocks dominated by the region
// (MachineLoop or WebAssemblyException) header. This works when the entity is
// discontiguous.
MachineBasicBlock *getBottom(const SortRegion *R);
MachineBasicBlock *getBottom(const MachineLoop *ML);
MachineBasicBlock *getBottom(const WebAssemblyException *WE);
};
} // end namespace WebAssembly
} // end namespace llvm
#endif