Summary:
This is an intermediate change, it moves the non-notification logic from
Backend::notifyCycleBegin to runCycle().
Once the scheduler becomes part of the Execution stage
the explicit call to Scheduler::cycleEvent will disappear.
The logic for Dispatch::cycleEvent() can be in
the preExecute phase, which this patch addresses.
Reviewers: andreadb, RKSimon, courbet
Reviewed By: andreadb
Subscribers: tschuett, gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D47213
llvm-svn: 333029
Summary:
The logic of dispatch remains the same, but now DispatchUnit is a Stage (DispatchStage).
This change has the benefit of simplifying the backend runCycle() code.
The same logic applies, but it belongs to different components now. This is just a start,
eventually we will need to remove the call to the DispatchStage in Scheduler.cpp, but
that will be a separate patch. This change is mostly a renaming and moving of existing logic.
This change also encouraged me to remove the Subtarget (STI) member from the
Backend class. That member was used to initialize the other members of Backend
and to eventually call DispatchUnit::dispatch(). Now that we have Stages, we
can eliminate this by instantiating the DispatchStage with everything it needs
at the time of construction (e.g., Subtarget). That change allows us to call
DispatchStage::execute(IR) as we expect to call execute() for all other stages.
Once we add the Stage list (D46907) we can more cleanly call preExecute() on
all of the stages, DispatchStage, will probably wrap cycleEvent() in that
case.
Made some formatting and minor cleanups to README.txt. Some of the text
was re-flowed to stay within 80 cols.
Reviewers: andreadb, courbet, RKSimon
Reviewed By: andreadb, courbet
Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D46983
llvm-svn: 332652
Summary: This change will help us turn the DispatchUnit into its own stage.
Reviewers: andreadb, RKSimon, courbet
Reviewed By: andreadb, courbet
Subscribers: mgorny, tschuett, gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D46916
llvm-svn: 332493
Revision 332390 introduced a FetchStage class in llvm-mca.
By design, FetchStage owns all the instructions in-flight in the OoO Backend.
Before this change, new instructions were added to a DenseMap indexed by
instruction id. The problem with using a DenseMap is that elements are not
ordered by key. This was causing a massive slow down in method
FetchStage::postExecute(), which searches for instructions retired that can be
deleted.
This patch replaces the DenseMap with a std::map ordered by instruction index.
At the end of every cycle, we search for the first instruction which is not
marked as "retired", and we remove all the previous instructions before it.
This works well because instructions are retired in-order.
Before this patch, a debug build of llvm-mca (on my Ryzen linux machine) took
~8.0 seconds to simulate 3000 iterations of a x86 dot-product (a `vmulps,
vpermilps, vaddps, vpermilps, vaddps` sequence). With this patch, it now takes
~0.8s to run all the 3000 iterations.
llvm-svn: 332461
Summary:
This is just an idea, really two ideas. I expect some push-back,
but I realize that posting a diff is the most comprehensive way to express
these concepts.
This patch introduces a Stage class which represents the
various stages of an instruction pipeline. As a start, I have created a simple
FetchStage that is based on existing logic for how MCA produces
instructions, but now encapsulated in a Stage. The idea should become more concrete
once we introduce additional stages. The idea being, that when a stage completes,
the next stage in the pipeline will be executed. Stages are chained together
as a singly linked list to closely model a real pipeline. For now there is only one stage,
so the stage-to-stage flow of instructions isn't immediately obvious.
Eventually, Stage will also handle event notifications, but that functionality
is not complete, and not destined for this patch. Ideally, an interested party
can register for notifications from a particular stage. Callbacks will be issued to
these listeners at various points in the execution of the stage.
For now, eventing functionality remains similar to what it has been in mca::Backend.
We will be building-up the Stage class as we move on, such as adding debug output.
This patch also removes the unique_ptr<Instruction> return value from
InstrBuilder::createInstruction. An Instruction pointer is still produced,
but now it's up to the caller to decide how that item should be managed post-allocation
(e.g., smart pointer). This allows the Fetch stage to create instructions and
manage the lifetime of those instructions as it wishes, and not have to be bound to any
specific managed pointer type. Other callers of createInstruction might have different
requirements, and thus can manage the pointer to fit their needs. Another idea would be to push the
ownership to the RCU.
Currently, the FetchStage will wrap the Instruction
pointer in a shared_ptr. This allows us to remove the Instruction container in
Backend, which was probably going to disappear, or move, at some point anyways.
Note that I did run these changes through valgrind, to make sure we are not leaking
memory. While the shared_ptr comes with some additional overhead it relieves us
from having to manage a list of generated instructions, and/or make lookup calls
to remove the instructions.
I realize that both the Stage class and the Instruction pointer management
(mentioned directly above) are separate but related ideas, and probably should
land as separate patches; I am happy to do that if either idea is decent.
The main reason these two ideas are together is that
Stage::execute() can mutate an InstRef. For the fetch stage, the InstRef is populated
as the primary action of that stage (execute()). I didn't want to change the Stage interface
to support the idea of generating an instruction. Ideally, instructions are to
be pushed through the pipeline. I didn't want to draw too much of a
specialization just for the fetch stage. Excuse the word-salad.
Reviewers: andreadb, courbet, RKSimon
Reviewed By: andreadb
Subscribers: llvm-commits, mgorny, javed.absar, tschuett, gbedwell
Differential Revision: https://reviews.llvm.org/D46741
llvm-svn: 332390
Strictly speaking, this is not necessary for .cpp files. However, other .cpp
files from this same tool have it. This also matches what we do in other tools.
llvm-svn: 332334
The tool assumes that a zero-latency instruction that doesn't consume hardware
resources is an optimizable dependency-breaking instruction. That means, it
doesn't have to wait on register input operands, and it doesn't consume any
physical register. The PRF knows how to optimize it at register renaming stage.
llvm-svn: 332249
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
- Manual change to APInt
- Manually chage DOCS as regex doesn't match it.
In the transition period the DEBUG() macro is still present and aliased
to the LLVM_DEBUG() one.
Differential Revision: https://reviews.llvm.org/D43624
llvm-svn: 332240
Summary:
This patch eliminates many places where we originally needed to pass index
values to represent an instruction. The index is still used as a key, in various parts of
MCA. I'm not comfortable eliminating the index just yet. By burying the index in
the instruction, we can avoid exposing that value in many places.
Eventually, we should consider removing the Instructions list in the Backend
all together, it's only used to hold and reclaim the memory for the allocated
Instruction instances. Instead we could pass around a smart pointer. But that's
a separate discussion/patch.
Reviewers: andreadb, courbet, RKSimon
Reviewed By: andreadb
Subscribers: javed.absar, tschuett, gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D46367
llvm-svn: 331660
This patch also improves the description of a couple of flags in the view
options. With this change, the -help now specifies which views are enabled by
default.
llvm-svn: 331594
Summary:
This change makes the TimelineView source simpler to read and easier to modify in the future.
This patch introduces a class of static chars used as the display values in the TimelineView report, this change just eliminates a few magic characters.
Reviewers: andreadb, courbet, RKSimon
Reviewed By: andreadb
Subscribers: tschuett, gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D46409
llvm-svn: 331540
The logic remains the same. Eventually, I see the RCU acting as its own separate stage in the instruction pipeline.
Differential Revision: https://reviews.llvm.org/D46331
llvm-svn: 331316
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46290
llvm-svn: 331272
This fixes PR37293.
We can have scheduling classes with no write latency entries, that still consume
processor resources. We don't want to treat those instructions as zero-latency
instructions; they still have to be issued to the underlying pipelines, so they
still consume resource cycles.
This is likely to be a regression which I have accidentally introduced at
revision 330807. Now, if an instruction has a non-empty set of write processor
resources, we conservatively treat it as a normal (i.e. non zero-latency)
instruction.
llvm-svn: 331193
Summary: The instruction index was never referenced in the body. Just a minor cleanup.
Reviewers: andreadb
Reviewed By: andreadb
Subscribers: javed.absar, gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D46142
llvm-svn: 331001
With this patch, options to add/tweak views are all grouped together in the
-help output.
The new "View Options" category looks like this:
```
View Options:
-dispatch-stats - Print dispatch statistics
-instruction-info - Print the instruction info view
-instruction-tables - Print instruction tables
-register-file-stats - Print register file statistics
-resource-pressure - Print the resource pressure view
-retire-stats - Print retire control unit statistics
-scheduler-stats - Print scheduler statistics
-timeline - Print the timeline view
-timeline-max-cycles=<uint> - Maximum number of cycles in the timeline view. Defaults to 80 cycles
-timeline-max-iterations=<uint> - Maximum number of iterations to print in timeline view
```
llvm-svn: 330816
The instruction printer used by llvm-mca to generate the performance report now
defaults the output assembly format to the format used for the input assembly
file.
On x86, the asm format can be either AT&T or Intel, depending on the
presence/absence of directive `.intel_syntax`.
Users can still specify a different assembly dialect with the command line flag
-output-asm-variant=<uint>.
llvm-svn: 330733
Zero latency instructions are now scheduled the same way as other instructions.
Before this patch, there was a specialzed code path for those instructions.
All scheduler events are now generated from method `scheduleInstruction()` and
from method `cycleEvent()`. This will make easier to implement a "execution
stage", and let that stage publish all the scheduler events.
No functional change intended.
llvm-svn: 330723
We have a few functions that virtually all command wants to run on
process startup/shutdown. This patch adds InitLLVM class to do that
all at once, so that we don't need to copy-n-paste boilerplate code
to each llvm command's main() function.
Differential Revision: https://reviews.llvm.org/D45602
llvm-svn: 330046
Normally, the Scheduler prioritizes older instructions over younger instructions
during the instruction issue stage. In one particular case where a dependent
instruction had a schedule read-advance associated to one of the input operands,
this rule was not correctly applied.
This patch fixes the issue and adds a test to verify that we don't regress that
particular case.
llvm-svn: 330032
This patch moves part of the logic that notifies dispatch stall events from the
DispatchUnit to the Scheduler.
The main goal of this patch is to remove (yet another) dependency between the
DispatchUnit and the Scheduler. Before this patch, the DispatchUnit had to know
about `Scheduler::Event` and how to classify stalls due to the lack of scheduling
resources. This patch removes that knowledge and simplifies the logic in
DispatchUnit::checkScheduler.
This is another change done in preparation for the work to fix PR36663.
No functional change intended.
llvm-svn: 329835
This patch moves the logic that collects and analyzes dispatch events to the
DispatchStatistics view.
Added flag -dispatch-stats to print statistics related to the dispatch logic.
llvm-svn: 329708
