http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/15710/steps/build%20stage%201/logs/stdio
fails with:
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp: In function ‘llvm::Expected<const llvm::object::Elf_Mips_Options<ELFT>*> readMipsOptions(const uint8_t*, llvm::ArrayRef<unsigned char>&, bool&)’:
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp:3373:19: error: the value of ‘ExpectedSize’ is not usable in a constant expression
if (O->size < ExpectedSize)
^
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp:3369:10: note: ‘size_t ExpectedSize’ is not const
size_t ExpectedSize =
^
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp:3373:12: error: parse error in template argument list
if (O->size < ExpectedSize)
^
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp: In instantiation of ‘llvm::Expected<const llvm::object::Elf_Mips_Options<ELFT>*> readMipsOptions(const uint8_t*, llvm::ArrayRef<unsigned char>&, bool&) [with ELFT = llvm::object::ELFType<(llvm::support::endianness)0u, true>; uint8_t = unsigned char]’:
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp:3400:30: required from ‘void {anonymous}::ELFDumper<ELFT>::printMipsOptions() [with ELFT = llvm::object::ELFType<(llvm::support::endianness)0u, true>]’
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp:2878:21: required from ‘void {anonymous}::ELFDumper<ELFT>::printArchSpecificInfo() [with ELFT = llvm::object::ELFType<(llvm::support::endianness)0u, true>]’
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp:6999:1: required from here
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp:3373:5: error: ‘size’ is not a member template function
Fix: add 2 `const` words to variables.
`printMipsOptions()` and the test related has the following issues currently:
1) It does not check the value of Elf_Mips_Options<ELFT>::size field.
2) For ODK_REGINFO options it is possible to read past the end of buffer,
because there is no check against the `sizeof(Elf_Mips_RegInfo<ELFT>)`.
3) The error about the broken size is just printed to the standard output.
4) The binary input is used for the test.
5) There is no testing for multiple options in the .MIPS.options section,
though the code supports it.
6) Only llvm-readobj is tested, but not llvm-readelf.
7) "Unsupported MIPS options tag" message does not reveal the tag ID/name.
This patch fixes all of these points.
Differential revision: https://reviews.llvm.org/D84854
It turns out that findSectionByName can return
const Elf_Shdr * instead of Expected<>, because its
code never returns an error currently (it reports warnings instead).
Differential revision: https://reviews.llvm.org/D85135
See https://lists.llvm.org/pipermail/llvm-dev/2020-July/143373.html
"[llvm-dev] Multiple documents in one test file" for some discussions.
This patch has explored several alternatives. The current semantics are similar to
what @dblaikie proposed.
`split-file filename output` splits the input file into multiple parts separated by
regex `^(.|//)--- filename` and write each part to the file `output/filename`
(`filename` can include path separators).
Use case A (organizing input of different formats (e.g. linker
script+assembly) in one file).
```
# RUN: split-file %s %t
# RUN: llvm-mc %t/asm -o %t.o
# RUN: ld.lld -T %t/lds %t.o -o %t
This is sometimes better than the %S/Inputs/ approach because the user
can see the auxiliary files immediately and don't have to open another file.
# asm
...
# lds
...
```
Use case B (for utilities which don't have built-in input splitting
feature):
```
// RUN: split-file %s %t
// RUN: llc < %t/1.ll | FileCheck %s --check-prefix=CASE1
// RUN: llc < %t/2.ll | FileCheck %s --check-prefix=CASE2
Combing tests prudently can improve readability.
For example, when testing parsing errors if the recovery mechanism isn't possible,
grouping the tests in one file can more readily see test coverage/strategy.
//--- 1.ll
...
//--- 2.ll
...
```
Since this is a new utility, there is no git history concerns for
UpperCase variable names. I use lowerCase variable names like mlir/lld.
Reviewed By: jhenderson, lattner
Differential Revision: https://reviews.llvm.org/D83834
Archives can now be specified as input files the same way that object
files are. Archives will always be linked after all objects (regardless
of the relative order of the inputs) but before any dynamic libraries or
process symbols.
This patch also relaxes matching for slice triples in
StaticLibraryDefinitionGenerator in order to support this feature:
Vendors need not match if the source vendor is unknown.
We have a `findSectionByName` helper that tries to find a section
by it name. It is used in a few places, but never tested.
I'd like to reuse this helper for a different place.
For this, I've changed it to return Expected<> and now it
doesn't use `unwrapOrErr` anymore. It also now a member of
Dumper class and might report warnings.
Differential revision: https://reviews.llvm.org/D84651
The -phony-externals option adds a generator which explicitly defines any
otherwise unresolved externals as null. This transforms link-time
unresolved-symbol errors into potential runtime null pointer accesses
(if an unresolved external is actually accessed during execution).
This option can be useful in -harness mode to avoid having to mock a
large number of symbols that are not reachable at runtime (e.g. unused
methods referenced by a class vtable).
This prevents weak symbols from being immediately dead-stripped when not
directly referenced from the test harneess, enabling use of weak symbols
from the code under test.
Refactoring `Slice` class and function `createUniversalBinary` from
`llvm-lipo` into MachOUniversalWriter. This refactoring is necessary so
as to use the refactored code for creating universal binaries under
llvm-libtool-darwin.
Reviewed by alexshap, smeenai
Differential Revision: https://reviews.llvm.org/D84662
This patch makes the 'debug_aranges' entry optional. If the entry is
empty, yaml2obj will only emit the header for it.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D84921
The -harness option enables new testing use-cases for llvm-jitlink. It takes a
list of objects to treat as a test harness for any regular objects passed to
llvm-jitlink.
If any files are passed using the -harness option then the following
transformations are applied to all other files:
(1) Symbols definitions that are referenced by the harness files are promoted
to default scope. (This enables access to statics from test harness).
(2) Symbols definitions that clash with definitions in the harness files are
deleted. (This enables interposition by test harness).
(3) All other definitions in regular files are demoted to local scope.
(This causes untested code to be dead stripped, reducing memory cost and
eliminating spurious unresolved symbol errors from untested code).
These transformations allow the harness files to reference and interpose
symbols in the regular object files, which can be used to support execution
tests (including fuzz tests) of functions in relocatable objects produced by a
build.
This reduces the number of check-llvm failures by 500.
Ideally we'd have a codegen version of PassRegistry.def, or have all the
codegen passes ported and put into PassRegistry.def. But since that
doesn't exist yet, hardcode the list of codegen IR passes.
There are still codegen passes missing from this list, I'll add them
later as I stumble upon them.
Reviewed By: asbirlea, ychen
Differential Revision: https://reviews.llvm.org/D84872
This introduces the printRelocationsHelper() which now contains the common
code used by both GNU and LLVM output styles.
Differential revision: https://reviews.llvm.org/D83935
This reverts commit d054c7ee2e9f4f98af7f22a5b00a941eb919bd59.
There are discussions about the utility name, its functionality and user interface.
Revert before we reach consensus.
This patch refactors the llvm tools namely, llvm-stress and sancov,
as well as the llvm TableGen utility, to use the new InitLLVM
interface which encapsulates PrettyStackTrace.
This is from https://reviews.llvm.org/D70702, but only for LLVM.
Reviewed-by: Kai
Differential Revision: https://reviews.llvm.org/D83484
Currently, when dumping section headers, llvm-readelf
prints "RELR" for SHT_ANDROID_RELR/SHT_RELR sections.
The behavior was introduced in D47919 and revealed in D84330.
But "SHT_ANDROID_RELR" has a different value from "SHT_RELR".
Also, "SHT_ANDROID_REL/SHT_ANDROID_RELA" are printed as "ANDROID_REL/ANDROID_RELA",
what makes the handling of the "SHT_ANDROID_RELR" inconsistent.
This patch makes llvm-readelf to print "ANDROID_RELR" instead of "RELR".
Differential revision: https://reviews.llvm.org/D84393
PGO profile is usually more precise than sample profile. However, PGO profile
needs to be collected from loadtest and loadtest may not be representative
enough to the production workload. Sample profile collected from production
can be used as a supplement -- for functions cold in loadtest but warm/hot
in production, we can scale up the related function in PGO profile if the
function is warm or hot in sample profile.
The implementation contains changes in compiler side and llvm-profdata side.
Given an instr profile and a sample profile, for a function cold in PGO
profile but warm/hot in sample profile, llvm-profdata will either mark
all the counters in the profile to be -1 or scale up the max count in the
function to be above hot threshold, depending on the zero counter ratio in
the profile. The assumption is if there are too many counters being zero
in the function profile, the profile is more likely to cause harm than good,
then llvm-profdata will mark all the counters to be -1 indicating the
function is hot but the profile is unaccountable. In compiler side, if a
function profile with all -1 counters is seen, the function entry count will
be set to be above hot threshold but its internal profile will be dropped.
In the long run, it may be useful to let compiler support using PGO profile
and sample profile at the same time, but that requires more careful design
and more substantial changes to make two profiles work seamlessly. The patch
here serves as a simple intermediate solution.
Differential Revision: https://reviews.llvm.org/D81981
This patch helps teach llvm-readelf to emit a correct number spaces when
dumping in hex format.
Before this patch, when the hex data doesn't fill the 4th column, some
spaces are missing.
```
Hex dump of section '.sec':
0x00000000 00000000 00000000 00000000 00000000 ................
0x00000010 00000000 00000000 00000000 0000 ..............
```
After this patch:
```
Hex dump of section '.sec':
0x00000000 00000000 00000000 00000000 00000000 ................
0x00000010 00000000 00000000 00000000 0000 ..............
```
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D84640
Starting with Skylake, the LBR contains the precise number of cycles between the two
consecutive branches.
Making use of this will hopefully make the measurements more precise than the
existing methods of using RDTSC.
Differential Revision: https://reviews.llvm.org/D77422
New change: check for existence of field `cycles` in perf_branch_entry before enabling this mode.
This should prevent compilation errors when building for older kernel whose headers don't support it.
Much like with function reduction, there may be remaining unhandled uses
of function, in particular in blockaddress. And in constants we can't
RAUW it with undef, because undef is not a function.
Instead, let's try to pretent that in the remaining cases, the new
signature didn't change, by bitcasting it.
A new (previously crashing) test case added.
There may be other users of a function other than CallInsts,
but what's more important, we can't actually replace function pointer
with undef, because for constants, that would not preserve the type
and RAUW would assert.
In particular, that affects blockaddress, however it proves to be
prohibitively complex to come up with a good test involving blockaddress:
we'd need to both ensure that the function body survives until
this pass, and is not interesting in this pass.
Summary:
Recursion detection can be non-trivial. Currently, the state-of-the-art for LLVM,
as far as i'm concerned, is D72362 `[clang-tidy] misc-no-recursion: a new check`.
However, it is quite limited:
* It does very basic call-graph based analysis, in the sense it will report even dynamically-unreachable recursion.
* It is inherently limited to a single TU
* It is hard to gauge how problematic each recursion is in practice.
Some of that can be addressed by adding clang analyzer-based check,
then it would at least support multiple TU's.
However, we can approach this problem from another angle - dynamic run-time analysis.
We already have means to capture a run-time callgraph (XRay, duh),
and there are already means to reconstruct it within `llvm-xray` tool.
This proposes to add a `-recursive-calls-only` switch to the `account` tool.
When the switch is on, when re-constructing callgraph for latency reconstruction,
each time we enter/leave some function, we increment/decrement an entry for the function
in a "recursion depth" map. If, when we leave the function, said entry was at `1`,
then that means the function didn't call itself, however if it is at `2` or more,
then that means the function (possibly indirectly) called itself.
If the depth is 1, we don't account the time spent there,
unless within this call stack the function already recursed into itself.
Note that we don't pay for recursion depth tracking when `recursive-calls-only` is not on,
and the perf impact is insignificant (+0.3% regression)
The overhead of the option is actually negative, around -5.26% user time on a medium-sized (3.5G) XRay log.
As a practical example, that 3.5G log is a capture of the entire middle-end opt pipeline
at `-O3` for RawSpeed unity build. There are total of `5500` functions in the log,
however `-recursive-calls-only` says that `269`, or 5%, are recursive.
Having this functionality could be helpful for recursion eradication.
Reviewers: dberris, mboerger
Reviewed By: dberris
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84582
It doesn't really need to know where Timings are stored, it just needs
to be able to sort them, so MutableArrayRef is enough.
That uncovers an interesting quirk that it relied on
implicit double->int conversion for calculating percentiles.
We can happily turn function definitions into declarations,
thus obscuring their argument from being elided by this pass.
I don't believe there is a good reason to just ignore declarations.
likely even proper llvm intrinsics ones,
at worst the input becomes uninteresting.
The other question here is that all these transforms are all-or-nothing.
In some cases, should we be treating each use separately?
The main blocker here seemed to be that llvm::CloneFunctionInto()
does `&OldFunc->front()`, which inserts a nullptr into a densemap,
which is not happy about it and asserts.
replaceFunctionCalls() is very non-exhaustive, it only handles
CallInst's. Which means, by the time we drop old function,
there may still be uses of it lurking around.
Let's instead whack-a-mole them by all by replacing with undef.
I'm not sure this is the best handling, especially for calls, but IMO
poorly reduced input is much better than crashing reduction tool.
A (previously-crashing!) test added.
Fixes https://bugs.llvm.org/show_bug.cgi?id=46819
Terminator may have returned value, so we need to replace uses,
and in general handle invoke as a branch inst.
I'm not sure this is the best handling, but IMO poorly reduced
input is much better than crashing reduction tool.
A (previously-crashing!) test added.
Fixes https://bugs.llvm.org/show_bug.cgi?id=46818
ReduceFunctions could do it, but it also replaces *all* calls with undef,
so if any of undef replacements makes reduction uninteresting,
it won't work.
ReduceBasicBlocks also could do it, but well, it may take many guesses
for all the blocks of a function to happen to be out-of-chunk,
which is not a very efficient way to go about it.
So let's just do this first.
See https://lists.llvm.org/pipermail/llvm-dev/2020-July/143373.html
"[llvm-dev] Multiple documents in one test file" for some discussions.
`extract part filename` splits the input file into multiple parts separated by
regex `^(.|//)--- ` and extract the specified part to stdout or the
output file (if specified).
Use case A (organizing input of different formats (e.g. linker
script+assembly) in one file).
```
// RUN: extract lds %s -o %t.lds
// RUN: extract asm %s -o %t.s
// RUN: llvm-mc %t.s -o %t.o
// RUN: ld.lld -T %t.lds %t.o -o %t
This is sometimes better than the %S/Inputs/ approach because the user
can see the auxiliary files immediately and don't have to open another file.
```
Use case B (for utilities which don't have built-in input splitting
feature):
```
// RUN: extract case1 %s | llc | FileCheck %s --check-prefix=CASE1
// RUN: extract case2 %s | llc | FileCheck %s --check-prefix=CASE2
Combing tests prudently can improve readability.
This is sometimes better than having multiple test files.
```
Since this is a new utility, there is no git history concerns for
UpperCase variable names. I use lowerCase variable names like mlir/lld.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D83834
It is used for printing section headers in the GNU style
and the implementation can be simplified.
Differential revision: https://reviews.llvm.org/D84330
Summary:
If there was a single target to begin with, because a single target
can only occupy a single chunk, we couldn't increase granularity.
and would immediately give up.
Likewise, if we had multiple targets, if by the end we'd end up with
a single target, we wouldn't finish reducing it, it would always
end up being "interesting"
Reviewers: dblaikie, nickdesaulniers, diegotf
Reviewed By: dblaikie
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84318
This patch includes the supporting code that enables always
instrumenting the function entry block by default.
This patch will NOT the default behavior.
It adds a variant bit in the profile version, adds new directives in
text profile format, and changes llvm-profdata tool accordingly.
This patch is a split of D83024 (https://reviews.llvm.org/D83024)
Many test changes from D83024 are also included.
Differential Revision: https://reviews.llvm.org/D84261
It was requested in D84173 thread to not do it, because otherwise we extract and
check the name of the symbol table in LLVM style, but do not use it and
might report a warning which perhaps might be confusing.
Differential revision: https://reviews.llvm.org/D84231
These functions can be used to generate strings like
"SHT_?? section with index ?" to describe sections in error/warning messages,
what helps to simplify and generalize them.
Also this allows to isolate the following common code pattern:
`&Sec - &cantFail(Obj->sections()).front();`
Differential revision: https://reviews.llvm.org/D84240
The current behavior was introduced by me in D37567 and it is a bit strange. It prints the
"Error: ...." message to the errs() manually and stops dumping the group section which has this error.
This behavior is consistent with GNU though, but it is very inconsistent with what the regular llvm-readelf
code usually does/prints, so I suggest to change the implementation:
1) Instead of printing "Error: ...." to errs() - just report a warning.
2) Try to continue dumping the section.
3) Merge broken-group.test to group.text.
This is what this patch does.
Differential revision: https://reviews.llvm.org/D84170
We have an issue currently: we are trying to read the name of the SHT_DYNSYM section
very early and using `unwrapOrError` call for that.
The name is needed only for the GNU output. Because of the current logic, the tool
fails to dump the whole object when something is wrong with the name of the .dynsym section.
This patch delays reading the name and also allows it to be broken.
Differential revision: https://reviews.llvm.org/D84173
Add support for flattening archives while creating static libraries.
Hence, can now pass archives as input in addition to Mach-O binaries.
Furthermore, archives themselves must only conatain Mach-O binaries. As
per cctools' libtool's behavior, llvm-libtool-darwin does not flatten
archives recursively.
Reviewed by alexshap, smeenai, jhenderson
Differential Revision: https://reviews.llvm.org/D83520
Add support for creating static libraries when the input includes only
Mach-O binaries (and not libraries/archives themselves).
Reviewed by alexshap, Ktwu, smeenai, jhenderson, MaskRay, mtrent
Differential Revision: https://reviews.llvm.org/D83002
OptNoneInstrumentation is part of StandardInstrumentations. It skips
functions (or loops) that are marked optnone.
The feature of skipping optional passes for optnone functions under NPM
is gated on a -enable-npm-optnone flag. Currently it is by default
false. That is because we still need to mark all required passes to be
required. Otherwise optnone functions will start having incorrect
semantics. After that is done in following changes, we can remove the
flag and always enable this.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D83519
In an object file, a "PC Begin" field in a FDE is usually relocated by a
PC-relative relocation. Use a relocation-aware DWARFDataExtractor overload (with
DWARFContext and a reference to its internal .eh_frame representation) to decode
addresses correctly. In an object file, most sections have addresses of zero. So
the displayed addresses are almost always offsets relative to the start of the
associated text section.
DWARFContext::create handles .eh_frame and .rela.eh_frame by itself, so if there
are more than one .eh_frame (technically possible, but almost always erronerous
in practice), this will only handle the first one. Supporting multiple
.eh_frame is beyond the scope of this patch.
Reviewed By: grimar, jhenderson
Differential Revision: https://reviews.llvm.org/D84106
