Work towards the unification of MIR and debug output by printing
`<mcsymbol sym>` instead of `<MCSym=sym>`.
Only debug syntax is affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320685 91177308-0d34-0410-b5e6-96231b3b80d8
Work towards the unification of MIR and debug output by printing
`liveout(...)` instead of `<regliveout>`.
Only debug syntax is affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320683 91177308-0d34-0410-b5e6-96231b3b80d8
Work towards the unification of MIR and debug output by printing
`@foo` instead of `<ga:@foo>`.
Also print target flags in the MIR format since most of them are used on
global address operands.
Only debug syntax is affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320682 91177308-0d34-0410-b5e6-96231b3b80d8
Work towards the unification of MIR and debug output by printing
`$symbol` instead of `<es:symbol>`.
Only debug syntax is affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320681 91177308-0d34-0410-b5e6-96231b3b80d8
Work towards the unification of MIR and debug output by printing `%jump-table.0` instead of `<jt#0>`.
Only debug syntax is affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320566 91177308-0d34-0410-b5e6-96231b3b80d8
Work towards the unification of MIR and debug output by printing `target-index(target-specific) + 8` instead of `<ti#0+8>` and `target-index(target-specific) + 8` instead of `<ti#0-8>`.
Only debug syntax is affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320565 91177308-0d34-0410-b5e6-96231b3b80d8
Work towards the unification of MIR and debug output by printing
`%const.0 + 8` instead of `<cp#0+8>` and `%const.0 - 8` instead of
`<cp#0-8>`.
Only debug syntax is affected.
Differential Revision: https://reviews.llvm.org/D41116
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320564 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This makes it possible to run an arbitrary matcher on the value
contained within the Expected<T> object.
To do this, I've needed to fully spell out the matcher, instead of using
the shorthand MATCHER_P macro.
The slight gotcha here is that standard template deduction will fail if
one tries to match HasValue(47) against an Expected<int &> -- the
workaround is to use HasValue(testing::Eq(47)).
The explanations produced by this matcher have changed a bit, since now
we delegate to the nested matcher to print the value. Since these don't
put quotes around the value, I've changed our PrintTo methods to match.
Reviewers: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41065
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320561 91177308-0d34-0410-b5e6-96231b3b80d8
Headers/Implementation files should be named after the class they
declare/define.
Also eliminated an `#include "llvm/CodeGen/LiveIntervalAnalysis.h"` in
favor of `class LiveIntarvals;`
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320546 91177308-0d34-0410-b5e6-96231b3b80d8
In all cases except for this optimistic attempt to reuse memory, the
moved-from TinyPtrVector was left `empty()` at the end of this
assignment. Though using a container after it's been moved from can be a
bit sketchy, it's probably best to just be consistent here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320408 91177308-0d34-0410-b5e6-96231b3b80d8
When the lowest bits of the operands to an integer multiply are known, the low bits of the result are deducible.
Code to deduce known-zero bottom bits already existed, but this change improves on that by deducing known-ones.
Patch by: Pedro Ferreira
Reviewers: craig.topper, sanjoy, efriedma
Differential Revision: https://reviews.llvm.org/D34029
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320269 91177308-0d34-0410-b5e6-96231b3b80d8
Work towards the unification of MIR and debug output by refactoring the
interfaces.
Add support for operand subreg index as an immediate to debug printing
and use ::print in the MIRPrinter.
Differential Review: https://reviews.llvm.org/D40965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320209 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, when linking against libcmt from the MSVC runtime,
lld-link /verbose would show "Ignoring unknown symbol record
with kind 0x1006". It turns out this was because
TypeIndexDiscovery did not handle S_REGISTER records, so these
records were not getting properly remapped.
Patch by: Alexnadre Ganea
Differential Revision: https://reviews.llvm.org/D40919
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320108 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Make enum ModRefInfo an enum class. Changes to ModRefInfo values should
be done using inline wrappers.
This should prevent future bit-wise opearations from being added, which can be more error-prone.
Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40933
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320107 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This did not work because the ExpectedHolder was trying to hold the
value in an Optional<T*>. Instead of trying to mimic the behavior of
Expected and try to make ExpectedHolder work with references and
non-references, I simply store the reference to the Expected object in
the holder.
I also add a bunch of tests for these matchers, which have helped me
flesh out some problems in my initial implementation of this patch, and
uncovered the fact that we are not consistent in quoting our values in
the matcher output (which I also fix).
Reviewers: zturner, chandlerc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D40904
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320025 91177308-0d34-0410-b5e6-96231b3b80d8
This extends r319391. It teaches the segment builder to emit the right
completed segment when more than one region ends at the same location.
Fixes PR35495.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319990 91177308-0d34-0410-b5e6-96231b3b80d8
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319840 91177308-0d34-0410-b5e6-96231b3b80d8
comparison of symbol names.
SymbolStringPool is a thread-safe string pool that will be used in upcoming Orc
APIs to facilitate efficient storage and fast comparison of symbol name strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319839 91177308-0d34-0410-b5e6-96231b3b80d8
This is for PR35460.
Currently when LLD adds files to TarWriter it may pass the same file
multiple times. For example it happens for clang reproduce file which specifies
archive (.a) files more than once in command line.
Patch makes TarWriter to ignore files with the same path, so it will
add only the first one to archive.
Differential revision: https://reviews.llvm.org/D40606
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319750 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fix for the coverage segment builder.
If multiple regions must be popped off the active stack at once, and
more than one of them end at the same location, emit a segment using the
count from the most-recent completed region.
Fixes PR35437, rdar://35760630
Testing: invoked llvm-cov on a stage2 build of clang, additional unit
tests, check-profile
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319391 91177308-0d34-0410-b5e6-96231b3b80d8
The motivation behind this patch is that future directions require us to
be able to compute the hash value of records independently of actually
using them for de-duplication.
The current structure of TypeSerializer / TypeTableBuilder being a
single entry point that takes an unserialized type record, and then
hashes and de-duplicates it is not flexible enough to allow this.
At the same time, the existing TypeSerializer is already extremely
complex for this very reason -- it tries to be too many things. In
addition to serializing, hashing, and de-duplicating, ti also supports
splitting up field list records and adding continuations. All of this
functionality crammed into this one class makes it very complicated to
work with and hard to maintain.
To solve all of these problems, I've re-written everything from scratch
and split the functionality into separate pieces that can easily be
reused. The end result is that one class TypeSerializer is turned into 3
new classes SimpleTypeSerializer, ContinuationRecordBuilder, and
TypeTableBuilder, each of which in isolation is simple and
straightforward.
A quick summary of these new classes and their responsibilities are:
- SimpleTypeSerializer : Turns a non-FieldList leaf type into a series of
bytes. Does not do any hashing. Every time you call it, it will
re-serialize and return bytes again. The same instance can be re-used
over and over to avoid re-allocations, and in exchange for this
optimization the bytes returned by the serializer only live until the
caller attempts to serialize a new record.
- ContinuationRecordBuilder : Turns a FieldList-like record into a series
of fragments. Does not do any hashing. Like SimpleTypeSerializer,
returns references to privately owned bytes, so the storage is
invalidated as soon as the caller tries to re-use the instance. Works
equally well for LF_FIELDLIST as it does for LF_METHODLIST, solving a
long-standing theoretical limitation of the previous implementation.
- TypeTableBuilder : Accepts sequences of bytes that the user has already
serialized, and inserts them by de-duplicating with a hash table. For
the sake of convenience and efficiency, this class internally stores a
SimpleTypeSerializer so that it can accept unserialized records. The
same is not true of ContinuationRecordBuilder. The user is required to
create their own instance of ContinuationRecordBuilder.
Differential Revision: https://reviews.llvm.org/D40518
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319198 91177308-0d34-0410-b5e6-96231b3b80d8
