mirror of
https://github.com/FEX-Emu/FEX.git
synced 2026-10-12 06:00:39 +02:00
Alyssa Rosenzweig
676c9a9be6
Generally, there are three reasons to track progress: * Conditional optimizations. E.g. only run DCE if ConstProp succeeds. * Fixed point optimizations. E.g. keep running the opt loop until convergence. * Metadata shenianigans. None of these apply to FEX. We explicitly do not want a nonlinear pass ordering, instead we want just a few passes that each converge in a single iteration. We expect them all to make progress when run. As such, tracking progress is a waste of CPU cycles. Stop doing it. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
36 lines
740 B
C++
36 lines
740 B
C++
// SPDX-License-Identifier: MIT
|
|
#pragma once
|
|
|
|
#include "Common/BitSet.h"
|
|
#include <FEXCore/IR/IR.h>
|
|
#include <FEXCore/fextl/unordered_map.h>
|
|
#include <FEXCore/fextl/vector.h>
|
|
|
|
namespace FEXCore::IR::Validation {
|
|
|
|
struct BlockInfo {
|
|
bool HasExit;
|
|
const OrderedNode* BlockNode;
|
|
|
|
fextl::vector<OrderedNode*> Predecessors;
|
|
fextl::vector<OrderedNode*> Successors;
|
|
};
|
|
|
|
class RAValidation;
|
|
|
|
class IRValidation final : public FEXCore::IR::Pass {
|
|
public:
|
|
~IRValidation();
|
|
void Run(IREmitter* IREmit) override;
|
|
|
|
private:
|
|
|
|
BitSet<uint64_t> NodeIsLive;
|
|
OrderedNode* EntryBlock;
|
|
fextl::unordered_map<IR::NodeID, BlockInfo> OffsetToBlockMap;
|
|
size_t MaxNodes {};
|
|
|
|
friend class RAValidation;
|
|
};
|
|
} // namespace FEXCore::IR::Validation
|