| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove duplication: Both TestingGuide and TestSuiteMakefileGuide
would give a similar overview over the test-suite.
- Present cmake/lit as the default/normal way of running the test-suite:
- Move information about the cmake/lit testsuite into the new
TestSuiteGuide.rst file. Mark the remaining information in
TestSuiteMakefilesGuide.rst as deprecated.
- General simplification and shorting of language.
- Remove paragraphs about tests known to fail as everything should pass
nowadays.
- Remove paragraph about zlib requirement; it's not required anymore
since we copied a zlib source snapshot into the test-suite.
- Remove paragraph about comparison with "native compiler". Correctness is
always checked against reference outputs nowadays.
- Change cmake/lit quickstart section to recommend `pip` for installing
lit and use `CMAKE_C_COMPILER` and a cache file in the example as that
is what most people will end up doing anyway. Also a section about
compare.py to quickstart.
- Document `Bitcode` and `MicroBenchmarks` directories.
- Add section with commonly used cmake configuration options.
- Add section about showing and comparing result files via compare.py.
- Add section about using external benchmark suites.
- Add section about using custom benchmark suites.
- Add section about profile guided optimization.
- Add section about cross-compilation and running on external devices.
Differential Revision: https://reviews.llvm.org/D51465
llvm-svn: 341260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DispatchStatistics view.
This patch introduces the following changes to the DispatchStatistics view:
* DispatchStatistics now reports the number of dispatched opcodes instead of
the number of dispatched instructions.
* The "Dynamic Dispatch Stall Cycles" table now also reports the percentage of
stall cycles against the total simulated cycles.
This change allows users to easily compare dispatch group sizes with the
processor DispatchWidth.
Before this change, it was difficult to correlate the two numbers, since
DispatchStatistics view reported numbers of instructions (instead of opcodes).
DispatchWidth defines the maximum size of a dispatch group in terms of number of
micro opcodes.
The other change introduced by this patch is related to how DispatchStage
generates "instruction dispatch" events.
In particular:
* There can be multiple dispatch events associated with a same instruction
* Each dispatch event now encapsulates the number of dispatched micro opcodes.
The number of micro opcodes declared by an instruction may exceed the processor
DispatchWidth. Therefore, we cannot assume that instructions are always fully
dispatched in a single cycle.
DispatchStage knows already how to handle instructions declaring a number of
opcodes bigger that DispatchWidth. However, DispatchStage always emitted a
single instruction dispatch event (during the first simulated dispatch cycle)
for instructions dispatched.
With this patch, DispatchStage now correctly notifies multiple dispatch events
for instructions that cannot be dispatched in a single cycle.
A few views had to be modified. Views can no longer assume that there can only
be one dispatch event per instruction.
Tests (and docs) have been updated.
Differential Revision: https://reviews.llvm.org/D51430
llvm-svn: 341055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generated by the SummaryView.
This patch adds two new fields to the perf report generated by the SummaryView.
Fields are now logically organized into two small groups; only the second group
contains throughput indicators.
Example:
```
Iterations: 100
Instructions: 300
Total Cycles: 414
Total uOps: 700
Dispatch Width: 4
uOps Per Cycle: 1.69
IPC: 0.72
Block RThroughput: 4.0
```
This patch also updates the docs for llvm-mca.
Due to the nature of this change, several tests in the tools/llvm-mca directory
were affected, and had to be updated using script `update_mca_test_checks.py`.
llvm-svn: 340946
|
|
|
|
|
|
|
|
|
| |
The problems with benchmark build should be fixed now, but Windows
buildbots still run into errors seemingly because of the bug in
clang-cl. Because of that, benchmark shouldn't be built on Windows at
this point.
llvm-svn: 340905
|
|
|
|
|
|
|
| |
This patch adds an example on how to generate a Chrome Trace Viewer
loadable trace from an XRay trace.
llvm-svn: 340847
|
|
|
|
|
|
|
| |
Add `xray_mode=xray-basic` to the list of options in the "further
exploration" section of the doc.
llvm-svn: 340843
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although the benchmark regex-related build issue seems to be
fixed, it appears that benchmark library triggers some stage 2 clang-cl
bugs:
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/13495/steps/build%20stage%202/logs/stdio
The only sensible option now is to prevent benchmark library from
building in the default configuration.
llvm-svn: 340836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any
project could use it for benchmark generation. A dummy benchmark is
added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of
the build process.
The current version does not utilize LLVM LNT and LLVM CMake
infrastructure, but that might be sufficient for most users. Two
introduced CMake variables:
* `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark
targets
* `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated
benchmark targets to the list of default LLVM targets (i.e. if `ON`
benchmarks will be built upon standard build invocation, e.g. `ninja` or
`make` with no specific targets)
List of modifications:
* `BENCHMARK_ENABLE_TESTING` is disabled
* `BENCHMARK_ENABLE_EXCEPTIONS` is disabled
* `BENCHMARK_ENABLE_INSTALL` is disabled
* `BENCHMARK_ENABLE_GTEST_TESTS` is disabled
* `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled
Original discussion can be found here:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html
Reviewed by: dberris, lebedev.ri
Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines,
dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50894
llvm-svn: 340809
|
|
|
|
|
|
|
| |
This matches the de-facto behavior based on constant folding
and the default lowering to fmin/fmax.
llvm-svn: 340762
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, the SchedulerStatistics only printed the maximum number of
buffer entries consumed in each scheduler's queue at a given point of the
simulation.
This patch restructures the reported table, and adds an extra field named
"Average number of used buffer entries" to it.
This patch also uses different colors to help identifying bottlenecks caused by
high scheduler's buffer pressure.
llvm-svn: 340746
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit awkward in a handful of places where we didn't even have
an instruction and now we have to see if we can build one. But on the
whole, this seems like a win and at worst a reasonable cost for removing
`TerminatorInst`.
All of this is part of the removal of `TerminatorInst` from the
`Instruction` type hierarchy.
llvm-svn: 340701
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D48842
llvm-svn: 340677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most users won't have to worry about this as all of the
'getOrInsertFunction' functions on Module will default to the program
address space.
An overload has been added to Function::Create to abstract away the
details for most callers.
This is based on https://reviews.llvm.org/D37054 but without the changes to
make passing a Module to Function::Create() mandatory. I have also added
some more tests and fixed the LLParser to accept call instructions for
types in the program address space.
Reviewed By: bjope
Differential Revision: https://reviews.llvm.org/D47541
llvm-svn: 340519
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the plumbing for the Tiny code model for the AArch64 backend. This,
instead of loading addresses through the normal ADRP;ADD pair used in the Small
model, uses a single ADR. The 21 bit range of an ADR means that the code and
its statically defined symbols need to be within 1MB of each other.
This makes it mostly interesting for embedded applications where we want to fit
as much as we can in as small a space as possible.
Differential Revision: https://reviews.llvm.org/D49673
llvm-svn: 340397
|
|
|
|
| |
llvm-svn: 340335
|
|
|
|
| |
llvm-svn: 340246
|
|
|
|
|
|
|
|
|
| |
Improving readability, removing redundant contents.
Reviewers: hiraditya
Differential Revision: https://reviews.llvm.org/D50686
llvm-svn: 340131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
well as MIR parsing support for `MCSymbol` `MachineOperand`s.
The only real way to test pre- and post-instruction symbol support is to
use them in operands, so I ended up implementing that within the patch
as well. I can split out the operand support if folks really want but it
doesn't really seem worth it.
The functional implementation of pre- and post-instruction symbols is
now *completely trivial*. Two tiny bits of code in the (misnamed)
AsmPrinter. It should be completely target independent as well. We emit
these exactly the same way as we emit basic block labels. Most of the
code here is to give full dumping, MIR printing, and MIR parsing support
so that we can write useful tests.
The MIR parsing of MC symbol operands still isn't 100%, as it forces the
symbols to be non-temporary and non-local symbols with names. However,
those names often can encode most (if not all) of the special semantics
desired, and unnamed symbols seem especially annoying to serialize and
de-serialize. While this isn't perfect or full support, it seems plenty
to write tests that exercise usage of these kinds of operands.
The MIR support for pre-and post-instruction symbols was quite
straightforward. I chose to print them out in an as-if-operand syntax
similar to debug locations as this seemed the cleanest way and let me
use nice introducer tokens rather than inventing more magic punctuation
like we use for memoperands.
However, supporting MIR-based parsing of these symbols caused me to
change the design of the symbol support to allow setting arbitrary
symbols. Without this, I don't see any reasonable way to test things
with MIR.
Differential Revision: https://reviews.llvm.org/D50833
llvm-svn: 339962
|
|
|
|
|
|
|
|
|
| |
Try to improve these docs based on some recent questions that were
sent to llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125329.html
llvm-svn: 339949
|
|
|
|
|
|
|
|
| |
whitespace.
Clarify that you should not introduce trailing whitespace when making a commit and that you should not remove trailing whitespace that's unrelated to code you are changing or are about to change. Then clarified the developer policy around what is considered an obvious whitespace commit.
llvm-svn: 339455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a CommandGuide for llvm-objdump summarizing its usage along with some
general context.
Reviewers: beanz
Reviewed By: beanz
Subscribers: Eugene.Zelenko, llvm-commits
Differential Revision: https://reviews.llvm.org/D50034
llvm-svn: 339250
|
|
|
|
|
|
| |
by switching to `text` in another place.
llvm-svn: 339001
|
|
|
|
|
|
|
|
|
| |
The sphinx build bot is erroring on these examples for some unknown
reason, and really the dso_local doesn't seem to be relevant to the
example in any way so its cleaner to omit it. And now they will look
a bit more like other (successful) IR examples.
llvm-svn: 338998
|
|
|
|
|
|
|
| |
`llvm` syntax in Sphinx. This appears to just fail and create errors on
the docs buildbot.
llvm-svn: 338997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
highlighting syntax.
Most of them already were like this, and the Sphinx runs on the docs
build bot seems to be substantially more picky and/or not have support
for a bunch of the syntax here. Hopefully this will let it progress past
this.
My previous attempt to fix the syntax made the `opt` tool happy, but no
idea what the Sphinx stuff is really looking for, and the fact that
other blocks already just use `text` led me to this solution.
llvm-svn: 338983
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notably, just close two of the debug info metadata nodes early rather
than leaving them open with `...` which won't ever lex correctly. And
add the missing `:` on the count labels.
Slowly progressing through all of the warnings on the documentation
build bot. Sorry to do this one commit at a time, but despite my best
efforts I can't trigger these errors locally.
llvm-svn: 338982
|
|
|
|
|
|
|
|
|
|
|
| |
Sphinx syntax highlighter.
This example also doesn't really make sense. There is no control flow or
clarification of what the `Safe:` block exists to do... If we want
examples here, we should make them much more clear in addition to making
them well formed IR sequences.
llvm-svn: 338981
|
|
|
|
|
|
| |
Hopefully fixes an issue on the docs build bot.
llvm-svn: 338980
|
|
|
|
|
|
|
|
| |
This appears to produce a warning on the docs build bot. It doesn't
reproduce for me, likely because I have a newer (or more full featured)
pygments install.
llvm-svn: 338978
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sphinx.
We think the bot is updated now, so trying this again. I'm landing it
(with permission) as Michael is at a con at the moment.
Actual patch largely by Michael Spencer.
Differential Revision: https://reviews.llvm.org/D44910
llvm-svn: 338977
|
|
|
|
|
|
|
| |
Also fixed a few undecorated 'llvm-mca' references to be highlighted
with the 'program' emphasis.
llvm-svn: 338900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scheduler.
This patch is a follow-up to r338702.
We don't need to use a map to model the wait/ready/issued sets. It is much more
efficient to use a vector instead.
This patch gives us an average 7.5% speedup (on top of the ~12% speedup obtained
after r338702).
llvm-svn: 338883
|
|
|
|
|
|
|
|
|
| |
This patch replaces all the remaining occurrences of string "MCA" with
":program:`llvm-mca`". Somehow I missed those strings when I committed r338394.
This patch also improves section "Instruction Dispatch".
llvm-svn: 338881
|
|
|
|
| |
llvm-svn: 338556
|
|
|
|
| |
llvm-svn: 338537
|
|
|
|
| |
llvm-svn: 338415
|
|
|
|
| |
llvm-svn: 338410
|
|
|
|
| |
llvm-svn: 338394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch mostly copies the existing Instruction Flow, and stage descriptions
from the mca README. I made a few text tweaks, but no semantic changes,
and made reference to the "default pipeline." I also removed the internals
references (e.g., reference to class names and header files). I did leave the
LSUnit name around, but only as an abbreviated word for the load-store unit.
Reviewers: andreadb, courbet, RKSimon, gbedwell, filcab
Reviewed By: andreadb
Subscribers: tschuett, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D49692
llvm-svn: 338319
|
|
|
|
|
|
|
|
| |
This makes it easier for someone to copy-paste this line, change the path, and run the command.
Differential Revision: https://reviews.llvm.org/D49201
llvm-svn: 338254
|
|
|
|
|
|
|
|
|
| |
This should make the semantics of DIExpressions within llvm.dbg.{addr,
declare, value} easier to understand.
Differential Revision: https://reviews.llvm.org/D49572
llvm-svn: 338182
|
|
|
|
| |
llvm-svn: 338125
|
|
|
|
| |
llvm-svn: 338105
|
|
|
|
|
|
|
|
|
|
|
|
| |
In light of the recent changes to SmallVector in r335421, r337514, and
r337820, document its advantages over std::vector (see r175906 and
r266909).
Also add a release note.
https://reviews.llvm.org/D49748
llvm-svn: 338071
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update of supported oses.
Reviewers: dberris
Reviewed By: dberris
Differential Revision: https://reviews.llvm.org/D49789
llvm-svn: 338003
|
|
|
|
|
|
|
|
|
|
| |
Violating the invariants specified by attributes is undefined behavior.
Maybe we could use poison instead for some of the parameter attributes,
but I don't think it's worthwhile.
Differential Revision: https://reviews.llvm.org/D49041
llvm-svn: 337947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new JIT event listener supports generating profiling data for
the linux 'perf' profiling tool, allowing it to generate function and
instruction level profiles.
Currently this functionality is not enabled by default, but must be
enabled with LLVM_USE_PERF=yes. Given that the listener has no
dependencies, it might be sensible to enable by default once the
initial issues have been shaken out.
I followed existing precedent in registering the listener by default
in lli. Should there be a decision to enable this by default on linux,
that should probably be changed.
Please note that until https://reviews.llvm.org/D47343 is resolved,
using this functionality with mcjit rather than orcjit will not
reliably work.
Disregarding the previous comment, here's an example:
$ cat /tmp/expensive_loop.c
bool stupid_isprime(uint64_t num)
{
if (num == 2)
return true;
if (num < 1 || num % 2 == 0)
return false;
for(uint64_t i = 3; i < num / 2; i+= 2) {
if (num % i == 0)
return false;
}
return true;
}
int main(int argc, char **argv)
{
int numprimes = 0;
for (uint64_t num = argc; num < 100000; num++)
{
if (stupid_isprime(num))
numprimes++;
}
return numprimes;
}
$ clang -ggdb -S -c -emit-llvm /tmp/expensive_loop.c -o
/tmp/expensive_loop.ll
$ perf record -o perf.data -g -k 1 ./bin/lli -jit-kind=mcjit /tmp/expensive_loop.ll 1
$ perf inject --jit -i perf.data -o perf.jit.data
$ perf report -i perf.jit.data
- 92.59% lli jitted-5881-2.so [.] stupid_isprime
stupid_isprime
main
llvm::MCJIT::runFunction
llvm::ExecutionEngine::runFunctionAsMain
main
__libc_start_main
0x4bf6258d4c544155
+ 0.85% lli ld-2.27.so [.] do_lookup_x
And line-level annotations also work:
│ for(uint64_t i = 3; i < num / 2; i+= 2) {
│1 30: movq $0x3,-0x18(%rbp)
0.03 │1 38: mov -0x18(%rbp),%rax
0.03 │ mov -0x10(%rbp),%rcx
│ shr $0x1,%rcx
3.63 │ ┌──cmp %rcx,%rax
│ ├──jae 6f
│ │ if (num % i == 0)
0.03 │ │ mov -0x10(%rbp),%rax
│ │ xor %edx,%edx
89.00 │ │ divq -0x18(%rbp)
│ │ cmp $0x0,%rdx
0.22 │ │↓ jne 5f
│ │ return false;
│ │ movb $0x0,-0x1(%rbp)
│ │↓ jmp 73
│ │ }
3.22 │1 5f:│↓ jmp 61
│ │ for(uint64_t i = 3; i < num / 2; i+= 2) {
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D44892
llvm-svn: 337789
|
|
|
|
|
|
| |
Expand the abbreviation where it is first used, and use IPC elsewhere.
llvm-svn: 337739
|
|
|
|
|
|
| |
Looks like this bot hasn't been updated yet.
llvm-svn: 337731
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44910
llvm-svn: 337730
|