1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-18 18:42:46 +02:00
llvm-mirror/tools/llvm-mca/lib/Context.cpp

66 lines
2.4 KiB
C++
Raw Normal View History

//===---------------------------- Context.cpp -------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
/// \file
///
/// This file defines a class for holding ownership of various simulated
/// hardware units. A Context also provides a utility routine for constructing
/// a default out-of-order pipeline with fetch, dispatch, execute, and retire
/// stages.
///
//===----------------------------------------------------------------------===//
#include "Context.h"
[llvm-mca] Introduce the llvm-mca library and organize the directory accordingly. NFC. Summary: This patch introduces llvm-mca as a library. The driver (llvm-mca.cpp), views, and stats, are not part of the library. Those are separate components that are not required for the functioning of llvm-mca. The directory has been organized as follows: All library source files now reside in: - `lib/HardwareUnits/` - All subclasses of HardwareUnit (these represent the simulated hardware components of a backend). (LSUnit does not inherit from HardwareUnit, but Scheduler does which uses LSUnit). - `lib/Stages/` - All subclasses of the pipeline stages. - `lib/` - This is the root of the library and contains library code that does not fit into the Stages or HardwareUnit subdirs. All library header files now reside in the `include` directory and mimic the same layout as the `lib` directory mentioned above. In the (near) future we would like to move the library (include and lib) contents from tools and into the core of llvm somewhere. That change would allow various analysis and optimization passes to make use of MCA functionality for things like cost modeling. I left all of the non-library code just where it has always been, in the root of the llvm-mca directory. The include directives for the non-library source file have been updated to refer to the llvm-mca library headers. I updated the llvm-mca/CMakeLists.txt file to include the library headers, but I made the non-library code explicitly reference the library's 'include' directory. Once we eventually (hopefully) migrate the MCA library components into llvm the include directives used by the non-library source files will be updated to point to the proper location in llvm. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D50929 llvm-svn: 340755
2018-08-27 19:16:32 +02:00
#include "HardwareUnits/RegisterFile.h"
#include "HardwareUnits/RetireControlUnit.h"
#include "HardwareUnits/Scheduler.h"
#include "Stages/DispatchStage.h"
#include "Stages/EntryStage.h"
[llvm-mca] Introduce the llvm-mca library and organize the directory accordingly. NFC. Summary: This patch introduces llvm-mca as a library. The driver (llvm-mca.cpp), views, and stats, are not part of the library. Those are separate components that are not required for the functioning of llvm-mca. The directory has been organized as follows: All library source files now reside in: - `lib/HardwareUnits/` - All subclasses of HardwareUnit (these represent the simulated hardware components of a backend). (LSUnit does not inherit from HardwareUnit, but Scheduler does which uses LSUnit). - `lib/Stages/` - All subclasses of the pipeline stages. - `lib/` - This is the root of the library and contains library code that does not fit into the Stages or HardwareUnit subdirs. All library header files now reside in the `include` directory and mimic the same layout as the `lib` directory mentioned above. In the (near) future we would like to move the library (include and lib) contents from tools and into the core of llvm somewhere. That change would allow various analysis and optimization passes to make use of MCA functionality for things like cost modeling. I left all of the non-library code just where it has always been, in the root of the llvm-mca directory. The include directives for the non-library source file have been updated to refer to the llvm-mca library headers. I updated the llvm-mca/CMakeLists.txt file to include the library headers, but I made the non-library code explicitly reference the library's 'include' directory. Once we eventually (hopefully) migrate the MCA library components into llvm the include directives used by the non-library source files will be updated to point to the proper location in llvm. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D50929 llvm-svn: 340755
2018-08-27 19:16:32 +02:00
#include "Stages/ExecuteStage.h"
#include "Stages/RetireStage.h"
namespace llvm {
namespace mca {
std::unique_ptr<Pipeline>
Context::createDefaultPipeline(const PipelineOptions &Opts, InstrBuilder &IB,
SourceMgr &SrcMgr) {
const MCSchedModel &SM = STI.getSchedModel();
// Create the hardware units defining the backend.
auto RCU = llvm::make_unique<RetireControlUnit>(SM);
auto PRF = llvm::make_unique<RegisterFile>(SM, MRI, Opts.RegisterFileSize);
[llvm-mca][MC] Add the ability to declare which processor resources model load/store queues (PR36666). This patch adds the ability to specify via tablegen which processor resources are load/store queue resources. A new tablegen class named MemoryQueue can be optionally used to mark resources that model load/store queues. Information about the load/store queue is collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and `StoreQueueID`. Those two fields are identifiers for buffered resources used to describe the load queue and the store queue. Field `BufferSize` is interpreted as the number of entries in the queue, while the number of units is a throughput indicator (i.e. number of available pickers for loads/stores). At construction time, LSUnit in llvm-mca checks for the presence of extra processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If that information is available, and fields LoadQueueID and StoreQueueID are set to a value different than zero (i.e. the invalid processor resource index), then LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value declared by the two processor resources. With this patch, we more accurately track dynamic dispatch stalls caused by the lack of LS tokens (i.e. load/store queue full). This is also shown by the differences in two BdVer2 tests. Stalls that were previously classified as generic SCHEDULER FULL stalls, are not correctly classified either as "load queue full" or "store queue full". About the differences in the -scheduler-stats view: those differences are expected, because entries in the load/store queue are not released at instruction issue stage. Instead, those are released at instruction executed stage. This is the main reason why for the modified tests, the load/store queues gets full before PdEx is full. Differential Revision: https://reviews.llvm.org/D54957 llvm-svn: 347857
2018-11-29 13:15:56 +01:00
auto LSU = llvm::make_unique<LSUnit>(SM, Opts.LoadQueueSize,
Opts.StoreQueueSize, Opts.AssumeNoAlias);
auto HWS = llvm::make_unique<Scheduler>(SM, LSU.get());
// Create the pipeline stages.
auto Fetch = llvm::make_unique<EntryStage>(SrcMgr);
auto Dispatch = llvm::make_unique<DispatchStage>(STI, MRI, Opts.DispatchWidth,
*RCU, *PRF);
[llvm-mca] Refactor how execution is orchestrated by the Pipeline. This patch changes how instruction execution is orchestrated by the Pipeline. In particular, this patch makes it more explicit how instructions transition through the various pipeline stages during execution. The main goal is to simplify both the stage API and the Pipeline execution. At the same time, this patch fixes some design issues which are currently latent, but that are likely to cause problems in future if people start defining custom pipelines. The new design assumes that each pipeline stage knows the "next-in-sequence". The Stage API has gained three new methods: - isAvailable(IR) - checkNextStage(IR) - moveToTheNextStage(IR). An instruction IR can be executed by a Stage if method `Stage::isAvailable(IR)` returns true. Instructions can move to next stages using method moveToTheNextStage(IR). An instruction cannot be moved to the next stage if method checkNextStage(IR) (called on the current stage) returns false. Stages are now responsible for moving instructions to the next stage in sequence if necessary. Instructions are allowed to transition through multiple stages during a single cycle (as long as stages are available, and as long as all the calls to `checkNextStage(IR)` returns true). Methods `Stage::preExecute()` and `Stage::postExecute()` have now become redundant, and those are removed by this patch. Method Pipeline::runCycle() is now simpler, and it correctly visits stages on every begin/end of cycle. Other changes: - DispatchStage no longer requires a reference to the Scheduler. - ExecuteStage no longer needs to directly interact with the RetireControlUnit. Instead, executed instructions are now directly moved to the next stage (i.e. the retire stage). - RetireStage gained an execute method. This allowed us to remove the dependency with the RCU in ExecuteStage. - FecthStage now updates the "program counter" during cycleBegin() (i.e. before we start executing new instructions). - We no longer need Stage::Status to be returned by method execute(). It has been dropped in favor of a more lightweight llvm::Error. Overally, I measured a ~11% performance gain w.r.t. the previous design. I also think that the Stage interface is probably easier to read now. That being said, code comments have to be improved, and I plan to do it in a follow-up patch. Differential revision: https://reviews.llvm.org/D50849 llvm-svn: 339923
2018-08-16 21:00:48 +02:00
auto Execute = llvm::make_unique<ExecuteStage>(*HWS);
auto Retire = llvm::make_unique<RetireStage>(*RCU, *PRF);
// Pass the ownership of all the hardware units to this Context.
addHardwareUnit(std::move(RCU));
addHardwareUnit(std::move(PRF));
addHardwareUnit(std::move(LSU));
addHardwareUnit(std::move(HWS));
// Build the pipeline.
auto StagePipeline = llvm::make_unique<Pipeline>();
[llvm-mca] Refactor how execution is orchestrated by the Pipeline. This patch changes how instruction execution is orchestrated by the Pipeline. In particular, this patch makes it more explicit how instructions transition through the various pipeline stages during execution. The main goal is to simplify both the stage API and the Pipeline execution. At the same time, this patch fixes some design issues which are currently latent, but that are likely to cause problems in future if people start defining custom pipelines. The new design assumes that each pipeline stage knows the "next-in-sequence". The Stage API has gained three new methods: - isAvailable(IR) - checkNextStage(IR) - moveToTheNextStage(IR). An instruction IR can be executed by a Stage if method `Stage::isAvailable(IR)` returns true. Instructions can move to next stages using method moveToTheNextStage(IR). An instruction cannot be moved to the next stage if method checkNextStage(IR) (called on the current stage) returns false. Stages are now responsible for moving instructions to the next stage in sequence if necessary. Instructions are allowed to transition through multiple stages during a single cycle (as long as stages are available, and as long as all the calls to `checkNextStage(IR)` returns true). Methods `Stage::preExecute()` and `Stage::postExecute()` have now become redundant, and those are removed by this patch. Method Pipeline::runCycle() is now simpler, and it correctly visits stages on every begin/end of cycle. Other changes: - DispatchStage no longer requires a reference to the Scheduler. - ExecuteStage no longer needs to directly interact with the RetireControlUnit. Instead, executed instructions are now directly moved to the next stage (i.e. the retire stage). - RetireStage gained an execute method. This allowed us to remove the dependency with the RCU in ExecuteStage. - FecthStage now updates the "program counter" during cycleBegin() (i.e. before we start executing new instructions). - We no longer need Stage::Status to be returned by method execute(). It has been dropped in favor of a more lightweight llvm::Error. Overally, I measured a ~11% performance gain w.r.t. the previous design. I also think that the Stage interface is probably easier to read now. That being said, code comments have to be improved, and I plan to do it in a follow-up patch. Differential revision: https://reviews.llvm.org/D50849 llvm-svn: 339923
2018-08-16 21:00:48 +02:00
StagePipeline->appendStage(std::move(Fetch));
StagePipeline->appendStage(std::move(Dispatch));
StagePipeline->appendStage(std::move(Execute));
StagePipeline->appendStage(std::move(Retire));
return StagePipeline;
}
} // namespace mca
} // namespace llvm