According to the documentation, lto_module_create_in_codegen_context
should return NULL on error but currently it is accidentally return
error_code. Since this is a bug fix and it seems to be a one-off bug
that only affects this API, there is no need to bump API version.
rdar://101505192
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D136769
In `computeInlinedContextSizeForRange`, the offset of range is only used one time, there is no need to cache the frame location stack.
Measured on one internal service binary, this can save 2GB memory usage and reduce a small run time (avoid one hash search).
Reviewed By: hoy, wenlei
Differential Revision: https://reviews.llvm.org/D128859
getNonRedundantWriteProcRes was assuming that tblgen topologically sorted the cpu ModelProcResources[] arrays so that resource units were declared before the resource groups that used them, but unfortunately that doesn't appear to be true - in most cases it was just getting lucky based off the alphanumeric sorting that was being performed and the choice of the resource pipe names in most scheduler models (Intel models in particular).
This patch adds an explicit sort, based off llvm-mca's initializeUsedResources, that sorts by resource mask - I'm hoping this basic sorting is enough, I don't think overlapping groups or Super resources are a problem.
I'd like to take this further in the future and start sharing more code between llvm-mca and llvm-exegesis - while triaging this bug I saw how similar both approaches are, but are just dissimilar enough that any refactor isn't going to be trivial :(
Working with @courbet on a follow up unit test
Fixes#58500Fixes#37045
Differential Revision: https://reviews.llvm.org/D136351
Copy this technique from bugpoint. Before trying to blindly
delete blocks, try to fold branch conditions. This intuitively
makes more sense for a faster reduction, since you can find
dead paths in the function to prune out before trying to bisect
blocks in source order.
Seems to provide some speedup on my multi-hour reduction samples.
This does have the potential to produce testcases with unreachable
blocks. This is already a problem with the existing block
reduction pass. I'm struggling dealing with invalid reductions
in these cases, so in the future this should probably start
deleting those. However, I do sometimes try to reduce failures
in code that becomes unreachable, so I'm not totally sure
what to do here.
ce3c3cb2912425bb4367bfbe9a4c68a6d6f0a04a broke this by
speculatively making transforms before checking shouldKeep.
Originally I tried to roll back changes to the IR, but it's probably
best to not touch it before querying.
This was making decisions based on BBsToDelete, while being
used to determine BBsToDelete which doesn't really work.
Additionally, this is a lot of logic just to avoid deleting
the entry block when we can just skip it.
Make load and store non-atomic. Make the others monotonic.
We could probably try to incrementally relax the orderings; not sure
how useful that would be.
This doesn't touch objc-arc-contract because that's in the codegen pipeline.
However, this does move its corresponding initialize function into initializeCodegen().
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D135041
I often run llvm-reduce on IR that contains debug info, this prevents an
extra step of `opt -passes=strip` I do every time and will result in a
lot less invalid reductions around debug metadata.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D136208
So we don't over count the number of chunks and do unnecessary work reducing more chunks than exist.
This lowers some random reduction I tested with locally from 250s to 232s.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D136127
We randomly use outs() or errs(), which makes test logs confusing.
We also randomly add/don't add a line afterward.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D136130
This reverts commit 86e9181ded7c5b6aa67a3a84089fce850c84f27a.
Seems to be causing bot failures: https://lab.llvm.org/buildbot#builders/5/builds/28313
Plus as noted on D135632 it seems to interact badly with parallel reduction.
The current implementation outputs JSON in the following way:
[{'<filename>':{'FileSummary':{},...}}]
Using the filename as a key makes processing the JSON data awkward, and
should be avoided. This patch removes that outer key, since the
'FileSummary' data also includes a 'File' field, and so we lose no data.
Reviewed By: jhenderson, leonardchan
Differential Revision: https://reviews.llvm.org/D134843
llvm-debuginfo-analyzer is a command line tool that processes debug
info contained in a binary file and produces a debug information
format agnostic “Logical View”, which is a high-level semantic
representation of the debug info, independent of the low-level
format.
The code has been divided into the following patches:
1) Interval tree
2) Driver and documentation
3) Logical elements
4) Locations and ranges
5) Select elements
6) Warning and internal options
7) Compare elements
8) ELF Reader
9) CodeView Reader
Full details:
https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570
This patch:
Driver and documentation
- Command line options.
- Full documentation.
- String Pool table.
Reviewed By: psamolysov, probinson
Differential Revision: https://reviews.llvm.org/D125777
This updates the `--function-starts` argument to now accept 3 different
modes, `addrs` for just printing the addresses of the function starts
(previous behavior), `names` for just printing the names of the function
starts, and `both` to print them both side by side.
In general if you're debugging function starts issues it's useful to see
the symbol name alongside the address. This also mirrors Apple's
`dyldinfo -function_starts` command which prints both.
Differential Revision: https://reviews.llvm.org/D119050
This small patch adds a '--skip-branches' option to the llvm-cov export
options. This option allows branch coverage information to be skipped from the
exported LCOV directives if it's not needed. For now, this only works when
exporting LCOV (which is noted in the option description), but it can be
extended for JSON later if it makes sense.
Differential Revision: https://reviews.llvm.org/D135986
Cleanup: avoid referring to `std::vector<T>` members when `T` is incomplete.
This is [not legal](https://timsong-cpp.github.io/cppwp/n4868/vector#overview-4)
according to the C++ standard, and causes build errors in particular in C++20
mode. Fix it by defining the vector's type before using the vector.
Reviewed By: saugustine, MaskRay
Differential Revision: https://reviews.llvm.org/D135906
This is to fix two issues related with loading address:
1) When multiple MMAPs occur and their loading address are different, before it only used the first MMap as base address, all perf address after it used the wrong base address.
2) For pseudo probe profile, the address is always based on preferred loading address. If the base address is not equal to the preferred loading address, the pseudo probe address query will be wrong.
Solution: Instead of converting the address to offset lazily, right now all the address after parsing are converted on the fly based on preferred loading address in the parsing time. There is no "offset" used in profile generator any more.
Reviewed By: hoy, wenlei
Differential Revision: https://reviews.llvm.org/D126827
The llvm-driver, enabled with LLVM_TOOL_LLVM_DRIVER_BUILD combines many llvm executables
into one to save overall toolchain size. This patch adds the capability for lld to be part of the
llvm-driver.
Differential Revision: https://reviews.llvm.org/D127472
The e_flags of existing object files are all 0x3 which happens to be
compatible. From this commit on, all LoongArch objects produced with
upstream LLVM will be of object file ABI v1, which is already supported
by binutils' master branch (to be released as 2.40), and is allowed by
the same binutils version to interlink with v0 objects so the existing
distributions have time to migrate.
Differential Revision: https://reviews.llvm.org/D134601
When reducing llvm-reduce with llvm-reduce, it can be confusing
to figure out what lines are printed by the child or parent. Not
sure this is the most reliable way to set and restore this.
Try some dumb strength reductions to "simpler" opcodes.
Make some opcode substitutions I typically try to get smaller
MIR out of codegen. This is a bit target specific and I have a
lot of increasingly target specific modifications I try
during manual reduction.
In a testcase I'm working on, the old write out and count IR lines
was taking about 200-300ms per iteration. This drops it out of the
profile.
This doesn't account for everything, but it doesn't seem to matter.
We should probably try to account for metadata and constantexpr tree
depths.
Verify all the requested passes exist before trying to run any.
For long reductions, it was really annoying for it to get halfway through
and then I come back later to an incomplete reduction.
Also add a new skip-delta-passes flag. Most of the time I want to opt out
of specific reductions, rather than run a select few.
This new opcode was initially documented as "pac_sign_return_address"
in https://github.com/MicrosoftDocs/cpp-docs/pull/4202, but was
soon afterwards renamed into "pac_sign_lr" in
https://github.com/MicrosoftDocs/cpp-docs/pull/4209, as the other
name was unwieldy, and there were no other external references to
that name anywhere.
Rename our external .seh assembler directive - it hasn't been merged
for very long yet, so there's probably no external use to account for.
Rename all other internal references to the opcode similarly.
Differential Revision: https://reviews.llvm.org/D135762
When zlib is disabled at build time, the diagnostic `LLVM was not compiled with
LLVM_ENABLE_ZLIB: cannot decompress` for --decompress-debug-sections may be
inaccurate: if zstd is enabled, we should still support zstd decompression.
It's not useful to test zlib and zstd. Just remove the diagnostic and add a new
one before `compression::decompress`.
This fixes compress-debug-sections-zstd.test
Reviewed By: mariusz-sikora-at-amd, jhenderson, phosek
Differential Revision: https://reviews.llvm.org/D135744
Add a check (can be disabled via a flag) that the pipeline we generate is actually parsable.
Can be disabled because we don't expect to handle every pass in -print-pipeline-passes.
Fixes#58280.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D135703
The previous calculations seem to have assumed that the section address would be zero.
This is true for relocatable object files, but certainly not for linked files like shared libraries.
Fixed the calculations to make them identical to the "real" `getInstruction` call below & added a regression test.
Reviewed By: scott.linder, simon_tatham
Differential Revision: https://reviews.llvm.org/D135430
Without this patch, we hit the following a lot:
"llvm.dbg.declare intrinsic requires a !dbg attachment"
"DICompileUnit not listed in llvm.dbg.cu"
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D135492
Phis have a quirk where the same predecessor block may appear multiple times
if the same block branches to it multiple ways. All the values need to match,
but this was replacing each operand independently. If an operand can be simplified,
make sure to replace every instance of the incoming block's value.
