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
Currently debugify prints it's output to stdout,
with this patch all the output generated goes to stderr.
This change lets us use debugify without taking away
the ability to pipe the output to other llvm tools.
llvm-svn: 332642
Summary:
Warn on instructions that should have the same performance
characteristics according to the sched model but actually
differ in their benchmarks.
Next step: Make the display nicer to browse, I was thinking maybe html.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D46945
llvm-svn: 332601
Restructuring the code to measure latency and uops.
The end goal is to have this program spawn another process to deal with SIGILL and other malformed programs. It is not yet the case in this redesign, it is still the main program that runs the code (and may crash).
It now uses BitVector instead of Graph for performance reasons.
https://reviews.llvm.org/D46821
(with fixed ARM tests)
Authored by Guillaume Chatelet
llvm-svn: 332592
Restructuring the code to measure latency and uops.
The end goal is to have this program spawn another process to deal with SIGILL and other malformed programs. It is not yet the case in this redesign, it is still the main program that runs the code (and may crash).
It now uses BitVector instead of Graph for performance reasons.
https://reviews.llvm.org/D46821
Authored by Guillaume Chatelet
llvm-svn: 332579
Fuchsia uses ELF as a file format and LLD as the linker so we can
use the same implementation as other ELF based platforms.
Differential Revision: https://reviews.llvm.org/D46991
llvm-svn: 332570
VSOs now track dependencies for materializing symbols. Each symbol must have its
dependencies registered with the VSO prior to finalization. Usually this will
involve registering the dependencies returned in
AsynchronousSymbolQuery::ResolutionResults for queries made while linking the
symbols being materialized.
Queries against symbols are notified that a symbol is ready once it and all of
its transitive dependencies are finalized, allowing compilation work to be
broken up and moved between threads without queries returning until their
symbols fully safe to access / execute.
Related utilities (VSO, MaterializationUnit, MaterializationResponsibility) are
updated to support dependence tracking and more explicitly track responsibility
for symbols from the point of definition until they are finalized.
llvm-svn: 332541
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
The module ID numbering typically starts at 0 (in both the new and old
LTO APIs, used by linkers). Make llvm-lto consistent with that.
Split out of D46699.
llvm-svn: 332476
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
This option just keeps being a problem and really needs to be implemented
in some fashion. Implementing it properly requires some kind of
"replaceSectionReference" method because all the existing links need to be
maintained. The desired behavior is just for allocated sections to become
NOBITS but actually implementing that is rather tricky due to the current
design of llvm-objcopy. However converting allocated sections to NOBITS is
just an optimization and not something debuggers need. Debuggers can debug
a stripped executable and take an unstripped executable for that stripped
executable as input. Additionally allocated sections account for a very
small part of debug binaries so this optimization is quite small. I propose
that for the time being we implement this as a NOP so that people can use
llvm-objcopy where they need to, just in a sub-optimal way.
This option has already blocked a lot of people and its currently blocking me.
llvm-svn: 332396
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
This option permits to explicitly keep the specified
symbol so that it doesn't get removed.
Differential Revision: https://reviews.llvm.org/D46819
llvm-svn: 332356
Summary:
AsmTemplate becomes IntructionBenchmarkKey, which has three components.
This allows retreiving the opcode for analysis.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D46873
llvm-svn: 332348
Summary:
The analysis mode gives the user a clustered view of the measurement results.
Next steps are (requires the split ok AsmTemplate.Name into {mnemonic, mode}):
- Show the sched class.
- Highlight any inconsistencies with the checked-in data.
Reviewers: gchatelet
Subscribers: mgorny, llvm-commits, tschuett
Differential Revision: https://reviews.llvm.org/D46865
llvm-svn: 332344
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
Summary: Arm does not have a ret code per se.
Reviewers: gchatelet
Subscribers: mgorny, javed.absar, kristof.beyls, tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D45672
llvm-svn: 332331
Most of the handling is pretty straightforward; fetch the default
memory flags for the specific resource type before parsing the flags
and apply them on top of that, except that some flags imply others
and some flags clear more than one flag.
For icons and cursors, the flags set get passed on to all individual
single icon/cursor resources, while only some flags affect the icon/cursor
group resource.
For stringtables, the behaviour is pretty simple; the first stringtable
resource of a bundle sets the flags for the whole bundle.
The output of these tests match rc.exe byte for byte.
The actual use of these memory flags is deprecated and they have no
effect since Win16, but some resource script files may still happen
to have them in place.
Differential Revision: https://reviews.llvm.org/D46818
llvm-svn: 332329
Previously these fields were only read from this header for cursors,
while Planes was hardcoded to 1 for icons (with a comment that it was
unknown why this was needed) and BitCount was left at the value
read originally in the RESDIRENTRY.
This fixes the single byte that was differing for the icon/cursor test
compared to rc.exe.
This is based on research/testing by Nico Weber.
Differential Revision: https://reviews.llvm.org/D46816
llvm-svn: 332328
This adds a -debugify-each mode to opt which, when enabled, wraps each
{Module,Function}Pass in a pipeline with logic to add, check, and strip
synthetic debug info for testing purposes.
This mode can be used to test complex pipelines for debug info bugs, or
to collect statistics about the number of debug values & locations lost
throughout various stages of a pipeline.
Patch by Son Tuan Vu!
Differential Revision: https://reviews.llvm.org/D46525
llvm-svn: 332312
Change relocation output so that relocation information follows
individual instructions rather than clustering them at the end
of packets.
This change required shifting block of code but the actual change
is in HexagonPrettyPrinter's PrintInst.
Differential Revision: https://reviews.llvm.org/D46728
llvm-svn: 332283
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
comparison of integers of different signs: 'const unsigned long' and 'const int' [-Werror,-Wsign-compare]
unittests/tools/llvm-exegesis/BenchmarkResultTest.cpp:60:5: note: in instantiation of function template specialization 'testing::internal::EqHelper<false>::Compare<unsigned long, int>' requested here
ASSERT_EQ(FromDiskVector.size(), 1);
llvm-svn: 332230
The analysis mode gives the user a clustered view of the measurement results and
highlights any inconsistencies with the checked-in data.
llvm-svn: 332229
Summary:
The first foray into merging debug info into the echo tests.
- Add bindings to Module::getModuleFlagsMetadata() in the form of LLVMCopyModuleFlagsMetadata
- Add the opaque type LLVMModuleFlagEntry to represent Module::ModuleFlagEntry
- Add accessors for LLVMModuleFlagEntry's behavior, key, and metadata node.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: aprantl, JDevlieghere, llvm-commits, harlanhaskins
Differential Revision: https://reviews.llvm.org/D46792
llvm-svn: 332219
Summary:
InitLLVM already calls llvm_shutdown, but llc registers for shutdown
with llvm_shutdown_obj so it gets called twice. It's not hurting anything, but
it's also not useful, so don't do it.
Reviewers: ruiu
Subscribers: aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D46788
llvm-svn: 332174
This diff adds support for -remove-section to llvm-strip.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46567
llvm-svn: 332081
Summary: Move and correct LLVMDIBuilderCreateTypedef. This is the last API in DIBuilderBindings.h, so it is being removed and the C API will now be re-exported from IRBindings.h.
Reviewers: whitequark, harlanhaskins, deadalnix
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46725
llvm-svn: 332041
Reviewed by: dblaikie, JDevlieghere, espindola
Differential Revision: https://reviews.llvm.org/D44560
Summary:
The .debug_line parser previously reported errors by printing to stderr and
return false. This is not particularly helpful for clients of the library code,
as it prevents them from handling the errors in a manner based on the calling
context. This change switches to using llvm::Error and callbacks to indicate
what problems were detected during parsing, and has updated clients to handle
the errors in a location-specific manner. In general, this means that they
continue to do the same thing to external users. Below, I have outlined what
the known behaviour changes are, relating to this change.
There are two levels of "errors" in the new error mechanism, to broadly
distinguish between different fail states of the parser, since not every
failure will prevent parsing of the unit, or of subsequent unit. Malformed
table errors that prevent reading the remainder of the table (reported by
returning them) and other minor issues representing problems with parsing that
do not prevent attempting to continue reading the table (reported by calling a
specified callback funciton). The only example of this currently is when the
last sequence of a unit is unterminated. However, I think it would be good to
change the handling of unrecognised opcodes to report as minor issues as well,
rather than just printing to the stream if --verbose is used (this would be a
subsequent change however).
I have substantially extended the DwarfGenerator to be able to handle
custom-crafted .debug_line sections, allowing for comprehensive unit-testing
of the parser code. For now, I am just adding unit tests to cover the basic
error reporting, and positive cases, and do not currently intend to test every
part of the parser, although the framework should be sufficient to do so at a
later point.
Known behaviour changes:
- The dump function in DWARFContext now does not attempt to read subsequent
tables when searching for a specific offset, if the unit length field of a
table before the specified offset is a reserved value.
- getOrParseLineTable now returns a useful Error if an invalid offset is
encountered, rather than simply a nullptr.
- The parse functions no longer use `WithColor::warning` directly to report
errors, allowing LLD to call its own warning function.
- The existing parse error messages have been updated to not specifically
include "warning" in their message, allowing consumers to determine what
severity the problem is.
- If the line table version field appears to have a value less than 2, an
informative error is returned, instead of just false.
- If the line table unit length field uses a reserved value, an informative
error is returned, instead of just false.
- Dumping of .debug_line.dwo sections is now implemented the same as regular
.debug_line sections.
- Verbose dumping of .debug_line[.dwo] sections now prints the prologue, if
there is a prologue error, just like non-verbose dumping.
As a helper for the generator code, I have re-added emitInt64 to the
AsmPrinter code. This previously existed, but was removed way back in r100296,
presumably because it was dead at the time.
This change also requires a change to LLD, which will be committed separately.
llvm-svn: 331971
When preprocessing resource scripts (which can easily be done outside
of llvm-rc), included headers can leave behind C declarations (despite
preprocessing with -DRC_INVOKED), that can't be parsed by a resource
compiler.
This is handled in all of rc.exe, by parsing the preprocessor output
line markers and ignoring content from files named *.h and *.c,
documented at [1].
In addition to this filtering, strip out any other preprocessor directive
that is left behind (like pragmas) which also can't be handled by the
tokenizer.
The added test uses both standard #line markers (supported by rc.exe) and
GNU style extended line markers, thus this test doesn't pass with rc.exe,
but passes with GNU windres. (Windres on the other hand doesn't filter
out files named *.c, only *.h.)
Differential Revision: https://reviews.llvm.org/D46579
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa381033(v=vs.85).aspx
llvm-svn: 331903
This is the same as any other user defined resource, but with
a specific allocated resource type number.
Differential Revision: https://reviews.llvm.org/D46636
llvm-svn: 331902
-1 is commonly used as ID for controls that one don't want to
refer to later. For DIALOG resources, the IDs are 16 bit numbers,
and -1 gets interpreted as UINT32_MAX earlier, which then later is
too large to write into a uint16_t.
Differential Revision: https://reviews.llvm.org/D46506
llvm-svn: 331901
Set the exit code to 1 if no arguments are specified.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46547
llvm-svn: 331776
Regardless of what docs may say, existing resource files in the
wild can use this syntax.
Rename a file used in an existing test, to make it usable for unquoted
paths.
Differential Revision: https://reviews.llvm.org/D46511
llvm-svn: 331747
Normally when writing something that requires padding, we first
measure the length of the written payload data, then write
padding if necessary.
For a recursive structure like versioninfo, this means that the
padding is excluded from the size of the inner element, but
included in the size of the enclosing block.
Rc.exe excludes the final padding (but not the padding of earlier
children) from all levels of the hierarchy.
To achieve this, don't pad after each block or value, but only
before starting the next one. We still pad after completing the
toplevel versioninfo resource, so this won't affect other resource
types.
Differential Revision: https://reviews.llvm.org/D46510
llvm-svn: 331668
llvm-strip is supposed to be a drop-in replacement for binutils strip.
To start the ball rolling this diff adds the initial bits for llvm-strip,
more features will be added incrementally over time.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46407
llvm-svn: 331663
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:
Set setDiagnosticsHotnessRequested before the early exit check for a
diagnostic output file, so that pass remarks with hotness works when
emitting pass remarks to stderr (e.g. via -pass-remarks=.).
Also fix the llvm-lto2 diagnistic handler so that it only calls exit(1)
when the diagnistic is an error type. Otherwise the new test invocation
of llvm-lto2 with -pass-remarks causes it to fail. The new code is
consistent with the diagnostic handler elsewhere (e.g. on the
LLVMContext).
Reviewers: pcc, davide
Subscribers: fhahn, mehdi_amini, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D46387
llvm-svn: 331569
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
Previously we were emitting the "cooked" alignment, which made it hard
to distinguish between that and the default alignment.
Differential Revision: https://reviews.llvm.org/D46418
llvm-svn: 331537
Only support UTF-8 (since LLVM contains UTF-8 parsing support
already, and the code even does that already) and Windows-1252
(where most code points has the same value in unicode). Keep the
existing default as only allowing ASCII input.
Using the option type JoinedOrSeparate, since the real rc.exe
handles options in this form, even if llvm-rc uses Separate for
other similar existing options.
Rename the struct SearchParams to WriterParams since it's now used
for more than just include paths.
Add a missing getResourceTypeName method to the BundleResource class,
to fix error printing from within STRINGTABLE resources (used in
tests).
Differential Revision: https://reviews.llvm.org/D46238
llvm-svn: 331391
Summary:
This brings the filenames in accordance to the style guide and LLVM
conventions for C++ filenames.
As suggested by rnk@ in D46068.
Reviewers: rnk
Subscribers: mgorny, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D46301
llvm-svn: 331321
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
Clement Courbet