The patch adds support for --hash-filenames to llvm-cov. This option adds md5
hash of the source path to the name of the generated .gcov file. The option is
crucial for cases where you have multiple files with the same name but can't
use --preserve-paths as resulting filenames exceed the limit.
from gcov(1):
```
-x
--hash-filenames
By default, gcov uses the full pathname of the source files to to
create an output filename. This can lead to long filenames that
can overflow filesystem limits. This option creates names of the
form source-file##md5.gcov, where the source-file component is
the final filename part and the md5 component is calculated from
the full mangled name that would have been used otherwise.
```
Patch by Igor Ignatev!
Differential Revision: https://reviews.llvm.org/D58370
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354379 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Up until the point i have looked in the source, i didn't even understood that
i can disable 'cluster' output. I have always silenced it via ` &> /dev/null`.
(And hoped it wasn't contributing much of the run time.)
While i expect that it has it's use-cases i never once needed it so far.
If i forget to silence it, console is completely flooded with that output.
How about not expecting users to opt-out of analyses,
but to explicitly specify the analyses that should be performed?
Reviewers: courbet, gchatelet
Reviewed By: courbet
Subscribers: tschuett, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57648
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353021 91177308-0d34-0410-b5e6-96231b3b80d8
If a stack trace or similar has a list of addresses from an executable
or DSO loaded at a variable address (e.g. due to ASLR), the addresses
will not directly correspond to the addresses stored in the object file.
If a user wishes to use llvm-symbolizer, they have to subtract the load
address from every address. This is somewhat inconvenient, especially as
the output of --print-address will result in the adjusted address being
listed, rather than the address coming from the stack trace, making it
harder to map results between the two.
This change adds a new switch to llvm-symbolizer --adjust-vma which
takes an offset, which is then used to automatically do this
calculation. The printed address remains the input address (allowing for
easy mapping), whilst the specified offset is applied to the addresses
when performing the lookup.
The switch is conceptually similar to llvm-objdump's new switch of the
same name (see D57051), which in turn mirrors a GNU switch. There is no
equivalent switch in addr2line.
Reviewed by: grimar
Differential Revision: https://reviews.llvm.org/D57151
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352195 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds two options, -i and -inlines as aliases for the -inlining option to llvm-symbolizer to improve compatibility with the GNU addr2line utility which accepts these options.
It also modifies existing tests that use -inlining to exercise these new aliases as well.
This fixes PR40073.
Reviewed by: jhenderson, Quolyk, ruiu
Differential Revision: https://reviews.llvm.org/D57083
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351999 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes https://bugs.llvm.org/show_bug.cgi?id=40072.
GNU addr2line's --functions switch is off by default, has a short alias
of -f, and does not take an argument. This patch changes llvm-symbolizer
to allow the second and third point (changing the default behaviour may
have negative impacts on users). If the option is missing a value, it
now treats it as "linkage".
This change does cause one previously valid command-line to behave
differently. Before --functions <value> was accepted, but now only
--functions=<value> is allowed (as well as --functions). The old
behaviour will result in the value being treated as a positional
argument.
The previous testing for --functions=short has been pulled out into a
new test that also tests the other accepted values and option formats.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D57049
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351968 91177308-0d34-0410-b5e6-96231b3b80d8
The old diagnostic form of the trace produced by -v and -vv looks
like:
```
check1:1:8: remark: CHECK: expected string found in input
CHECK: abc
^
<stdin>:1:3: note: found here
; abc def
^~~
```
When dumping annotated input is requested (via -dump-input), I find
that this old trace is not useful and is sometimes harmful:
1. The old trace is mostly redundant because the same basic
information also appears in the input dump's annotations.
2. The old trace buries any error diagnostic between it and the input
dump, but I find it useful to see any error diagnostic up front.
3. FILECHECK_OPTS=-dump-input=fail requests annotated input dumps only
for failed FileCheck calls. However, I have to also add -v or -vv
to get a full set of annotations, and that can produce massive
output from all FileCheck calls in all tests. That's a real
problem when I run this in the IDE I use, which grinds to a halt as
it tries to capture all that output.
When -dump-input=fail|always, this patch suppresses the old trace from
-v or -vv. Error diagnostics still print as usual. If you want the
old trace, perhaps to see variable expansions, you can set
-dump-input=none (the default).
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D55825
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351881 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds demangling support to the ELF side of llvm-readobj,
under the switch --demangle/-C.
The following places are demangled: symbol table dumps (static and
dynamic), relocation dumps (static and dynamic), addrsig dumps, call
graph profile dumps, and group section signature symbols.
Although GNU readelf doesn't support demangling, it is still a useful
feature to have, and brings it on a par with llvm-objdump's
capabilities.
This fixes https://bugs.llvm.org/show_bug.cgi?id=40054.
Reviewed by: grimar, rupprecht
Differential Revision: https://reviews.llvm.org/D56791
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351450 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When running llvm-objdump with the -macho option objdump will by default
disassemble only the __TEXT,__text section (or __TEXT_EXEC,__text when
disassembling MH_KEXT_BUNDLE files). The -disassemble-all option is
treated no diferently than -disassemble.
This change upates llvm-objdump's MachO parsing code to disassemble all
__text sections found in a file when -disassemble-all is specified. This
is useful for disassembling files with more than one __text section, or
when disassembling files whose __text section is not present in __TEXT.
I added a lit test case that verifies "llvm-objdump -m -d" and
"llvm-objdump -m -D" produce the expected results on a reference binary.
I also updated the CommandGuide documentation for llvm-objdump.rst and
verified it renders correctly as man and html.
rdar://42899338
Reviewers: ab, pete, lhames
Reviewed By: lhames
Subscribers: rupprecht, llvm-commits
Differential Revision: https://reviews.llvm.org/D56649
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351238 91177308-0d34-0410-b5e6-96231b3b80d8
Part of the effort to refactoring frame pointer code generation. We used
to use two function attributes "no-frame-pointer-elim" and
"no-frame-pointer-elim-non-leaf" to represent three kinds of frame
pointer usage: (all) frames use frame pointer, (non-leaf) frames use
frame pointer, (none) frame use frame pointer. This CL makes the idea
explicit by using only one enum function attribute "frame-pointer"
Option "-frame-pointer=" replaces "-disable-fp-elim" for tools such as
llc.
"no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" are still
supported for easy migration to "frame-pointer".
tests are mostly updated with
// replace command line args ‘-disable-fp-elim=false’ with ‘-frame-pointer=none’
grep -iIrnl '\-disable-fp-elim=false' * | xargs sed -i '' -e "s/-disable-fp-elim=false/-frame-pointer=none/g"
// replace command line args ‘-disable-fp-elim’ with ‘-frame-pointer=all’
grep -iIrnl '\-disable-fp-elim' * | xargs sed -i '' -e "s/-disable-fp-elim/-frame-pointer=all/g"
Patch by Yuanfang Chen (tabloid.adroit)!
Differential Revision: https://reviews.llvm.org/D56351
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351049 91177308-0d34-0410-b5e6-96231b3b80d8
This patch improves llvm-profdata show command:
(1) add -value-cutoff=<N> option: Show only those functions whose max count
values are greater or equal to N.
(2) add -list-below-cutoff option: Only output names of functions whose max
count value are below the cutoff.
(3) formats value-profile counts and prints out percentage.
Differential Revision: https://reviews.llvm.org/D56342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350673 91177308-0d34-0410-b5e6-96231b3b80d8
In LTO or Thin-lto mode (though linker plugin), the module
names are of temp file names which are different for
different compilations. Using SourceFileName avoids the issue.
This should not change any functionality for current PGO as
all the current callers of getPGOFuncName() is before LTO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350579 91177308-0d34-0410-b5e6-96231b3b80d8
Extend FileCheck to dump its input annotated with FileCheck's
diagnostics: errors, good matches if -v, and additional information if
-vv. The goal is to make it easier to visualize FileCheck's matching
behavior when debugging.
Each patch in this series implements input annotations for a
particular category of FileCheck diagnostics. While the first few
patches alone are somewhat useful, the annotations become much more
useful as later patches implement annotations for -v and -vv
diagnostics, which show the matching behavior leading up to the error.
This first patch implements boilerplate plus input annotations for
error diagnostics reporting that no matches were found for a
directive. These annotations mark the search ranges of the failed
directives. Instead of using the usual `^~~`, which is used by later
patches for good matches, these annotations use `X~~` so that this
category of errors is visually distinct.
For example:
```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:
- L: labels line number L of the input file
- T:L labels the match result for a pattern of type T from line L of
the check file
- X~~ marks search range when no match is found
- colors error
If you are not seeing color above or in input dumps, try: -color
$ FileCheck -v -dump-input=always check1 < input1 |& sed -n '/^Input file/,$p'
Input file: <stdin>
Check file: check1
-dump-input=help describes the format of the following dump.
Full input was:
<<<<<<
1: ; abc def
2: ; ghI jkl
next:3 X~~~~~~~~ error: no match found
>>>>>>
$ cat check1
CHECK: abc
CHECK-SAME: def
CHECK-NEXT: ghi
CHECK-SAME: jkl
$ cat input1
; abc def
; ghI jkl
```
Some additional details related to the boilerplate:
* Enabling: The annotated input dump is enabled by `-dump-input`,
which can also be set via the `FILECHECK_OPTS` environment variable.
Accepted values are `help`, `always`, `fail`, or `never`. As shown
above, `help` describes the format of the dump. `always` is helpful
when you want to investigate a successful FileCheck run, perhaps for
an unexpected pass. `-dump-input-on-failure` and
`FILECHECK_DUMP_INPUT_ON_FAILURE` remain as a deprecated alias for
`-dump-input=fail`.
* Diagnostics: The usual diagnostics are not suppressed in this mode
and are printed first. For brevity in the example above, I've
omitted them using a sed command. Sometimes they're perfectly
sufficient, and then they make debugging quicker than if you were
forced to hunt through a dump of long input looking for the error.
If you think they'll get in the way sometimes, keep in mind that
it's pretty easy to grep for the start of the input dump, which is
`<<<`.
* Colored Annotations: The annotated input is colored if colors are
enabled (enabling colors can be forced using -color). For example,
errors are red. However, as in the above example, colors are not
vital to reading the annotations.
I don't know how to test color in the output, so any hints here would
be appreciated.
Reviewed By: george.karpenkov, zturner, probinson
Differential Revision: https://reviews.llvm.org/D52999
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@349418 91177308-0d34-0410-b5e6-96231b3b80d8
RetireControlUnitStatistics now reports extra information about the ROB and the
avg/maximum number of entries consumed over the entire simulation.
Example:
Retire Control Unit - number of cycles where we saw N instructions retired:
[# retired], [# cycles]
0, 109 (17.9%)
1, 102 (16.7%)
2, 399 (65.4%)
Total ROB Entries: 64
Max Used ROB Entries: 35 ( 54.7% )
Average Used ROB Entries per cy: 32 ( 50.0% )
Documentation in llvm/docs/CommandGuide/llvmn-mca.rst has been updated to
reflect this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347493 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases it is desirable to match the same pattern repeatedly
many times. Currently the only way to do it is to copy the same
check pattern as many times as needed. And that gets pretty unwieldy
when its more than count is big.
Introducing CHECK-COUNT-<num> directive which acts like a plain CHECK
directive yet matches the same pattern exactly <num> times.
Extended FileCheckType to a struct to add Count there.
Changed some parsing routines to handle non-fixed length of directive
(all currently existing directives were fixed-length).
The code is generic enough to allow future support for COUNT in more
than just PlainCheck directives.
See motivating example for this feature in reviews.llvm.org/D54223.
Reviewed By: chandlerc, dblaikie
Differential Revision: https://reviews.llvm.org/D54336
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346722 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
lcov tracefiles are used by various coverage reporting tools and build
systems (e.g., Bazel). It is a simple text-based format to parse and
more convenient to use than the JSON export format, which needs
additional processing to map regions/segments back to line numbers.
It's a little unfortunate that "text" format is now overloaded to refer
specifically to JSON for export, but I wanted to avoid making any
breaking changes to the UI of the llvm-cov tool at this time.
Patch by Tony Allevato (@allevato).
Reviewers: Dor1s, vsk
Reviewed By: Dor1s, vsk
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D54266
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346506 91177308-0d34-0410-b5e6-96231b3b80d8
This feature makes it easy to tune FileCheck diagnostic output when
running the test suite via ninja, a bot, or an IDE. For example:
```
$ FILECHECK_OPTS='-color -v -dump-input-on-failure' \
LIT_FILTER='OpenMP/for_codegen.cpp' ninja check-clang \
| less -R
```
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D53517
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346272 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The pfm counters are now in the ExegesisTarget rather than the
MCSchedModel (PR39165).
This also compresses the pfm counter tables (PR37068).
Reviewers: RKSimon, gchatelet
Subscribers: mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D52932
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345243 91177308-0d34-0410-b5e6-96231b3b80d8
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345202 91177308-0d34-0410-b5e6-96231b3b80d8
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D53419
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344930 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We try to recover gracefully on instructions that would crash the
program.
This includes some refactoring of runMeasurement() implementations.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D53371
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344695 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is a step towards fixing PR38048.
Note that right now the measurements are given per instruction. We'll
need to give measurements a per code snippet and update the analysis (PR38731).
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D52041
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@342947 91177308-0d34-0410-b5e6-96231b3b80d8
add a tool to generate symbol remapping files.
Summary:
The new tool llvm-cxxmap builds a symbol mapping table from a file containing
a description of partial equivalences to apply to mangled names and files
containing old and new symbol tables.
Reviewers: davidxl
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D51470
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@342168 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@341055 91177308-0d34-0410-b5e6-96231b3b80d8
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`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340946 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340746 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340397 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339250 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338883 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338881 91177308-0d34-0410-b5e6-96231b3b80d8
