| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 305643
|
|
|
|
| |
llvm-svn: 305642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Suppose we had a type index offsets array with a boundary at type index
N. Then you request the name of the type with index N+1, and that name
requires the name of index N-1 (think a parameter list, for example). We
didn't handle this, and we would print something like (<unknown UDT>,
<unknown UDT>).
The fix for this is not entirely trivial, and speaks to a larger
problem. I think we need to kill TypeDatabase, or at the very least kill
TypeDatabaseVisitor. We need a thing that doesn't do any caching
whatsoever, just given a type index it can compute the type name "the
slow way". The reason for the bug is that we don't have anything like
that. Everything goes through the type database, and if we've visited a
record, then we're "done". It doesn't know how to do the expensive thing
of re-visiting dependent records if they've not yet been visited.
What I've done here is more or less copied the code (albeit greatly
simplified) from TypeDatabaseVisitor, but wrapped it in an interface
that just returns a std::string. The logic of caching the name is now in
LazyRandomTypeCollection. Eventually I'd like to move the record
database here as well and the visited record bitfield here as well, at
which point we can actually just delete TypeDatabase. I don't see any
reason for it if a "sequential" collection is just a special case of a
random access collection with an empty partial offsets array.
Differential Revision: https://reviews.llvm.org/D34297
llvm-svn: 305612
|
|
|
|
|
|
|
| |
We have to use ASSERT_XXX instead of EXPECT_XXX if the test cannot
continue in the failure case.
llvm-svn: 305522
|
|
|
|
| |
llvm-svn: 305519
|
|
|
|
|
|
| |
braces to avoid ambiguous 'else'. NFC.
llvm-svn: 305506
|
|
|
|
|
|
|
|
|
| |
Previously if you used fmt_align(7, Center) you would get the
output ' 7 '. It may be desirable for the user to specify
the fill character though, for example producing '---7---'. This
patch adds that.
llvm-svn: 305449
|
|
|
|
|
|
|
|
| |
Instead use target_link_libraries directly. Thanks to
Juergen Ributzka for the suggestion, which fixes an issue
when llvm is configured with no targets.
llvm-svn: 305421
|
|
|
|
| |
llvm-svn: 305403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many times unit tests for different libraries would like to use
the same helper functions for checking common types of errors.
This patch adds a common library with helpers for testing things
in Support, and introduces helpers in here for integrating the
llvm::Error and llvm::Expected<T> classes with gtest and gmock.
Normally, we would just be able to write:
EXPECT_THAT(someFunction(), succeeded());
but due to some quirks in llvm::Error's move semantics, gmock
doesn't make this easy, so two macros EXPECT_THAT_ERROR() and
EXPECT_THAT_EXPECTED() are introduced to gloss over the difficulties.
Consider this an exception, and possibly only temporary as we
look for ways to improve this.
Differential Revision: https://reviews.llvm.org/D33059
llvm-svn: 305395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: echristo, pcc, aprantl
Reviewed By: aprantl
Subscribers: fhahn, javed.absar, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D33894
llvm-svn: 305386
|
|
|
|
| |
llvm-svn: 305318
|
|
|
|
|
|
| |
DynamicLibraryTests compile flags.
llvm-svn: 305313
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the matching was done incorrectly for the case where
operands for FCmpInst and SelectInst were in opposite order.
Patch by Andrei Elovikov.
Differential Revision: https://reviews.llvm.org/D33185
llvm-svn: 305308
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: pcc, echristo, aprantl
Reviewed By: aprantl
Subscribers: fhahn, aprantl, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33892
llvm-svn: 305304
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes an issue using RegisterStandardPasses from a statically linked object before PassManagerBuilder::addGlobalExtension is called from a dynamic library.
Reviewers: efriedma, theraven
Reviewed By: efriedma
Subscribers: mehdi_amini, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D33515
llvm-svn: 305303
|
|
|
|
|
|
|
| |
On some compilers, __used__ can only be applied to variables
or functions.
llvm-svn: 305188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running unittests/Support/DynamicLibrary/DynamicLibraryTests fails
when LLVM is configured with -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON, because
the test's version script only contains symbols extracted from the static libraries,
that the test links with, but not those from the main object/executable itself.
The patch moves the one symbol, needed by the test, to a static library.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32893
Patch by Momchil Velikov.
Differential Revision: https://reviews.llvm.org/D33789
llvm-svn: 305181
|
|
|
|
| |
llvm-svn: 305168
|
|
|
|
| |
llvm-svn: 305166
|
|
|
|
|
|
|
|
|
| |
They're unused with recent versions of libstdc++ but older ones
(e.g. libstdc++ 4.9 still requires them). Maybe we should bump
the requirements on the minimum version to make GCC 7 happy, but
in the meanwhile we need to live with the warning.
llvm-svn: 305158
|
|
|
|
| |
llvm-svn: 305157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This prevents the iterator overrides from being selected in
the case where non-iterator types are used as arguments, which
is of particular importance in cases where other overrides with
identical types exist.
Reviewers: dblaikie, bkramer, rafael
Subscribers: llvm-commits, efriedma
Differential Revision: https://reviews.llvm.org/D33919
llvm-svn: 305105
|
|
|
|
|
|
|
|
|
|
|
| |
Previously extractors tried to be stateless with any additional
context information needed in order to parse items being passed
in via the extraction method. This led to quite cumbersome
implementation challenges and awkwardness of use. This patch
brings back support for stateful extractors, making the
implementation and usage simpler.
llvm-svn: 305093
|
|
|
|
| |
llvm-svn: 304945
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Check that the first access before one being tested is valid.
Before this patch, if there was no definition prior to the Use being tested,
the first time Iter was deferenced, it hit the sentinel.
Reviewers: dberlin, gbiv
Subscribers: sanjoy, Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33950
llvm-svn: 304926
|
|
|
|
| |
llvm-svn: 304871
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function
Seems like at least one reasonable interpretation of optnone is that the
optimizer never "looks inside" a function. This fix is consistent with
that interpretation.
Specifically this came up in the situation:
f3 calls f2 calls f1
f2 is always_inline
f1 is optnone
The application of readnone to f1 (& thus to f2) caused the inliner to
kill the call to f2 as being trivially dead (without even checking the
cost function, as it happens - not sure if that's also a bug).
llvm-svn: 304833
|
|
|
|
|
|
|
|
|
| |
Use `if (!X) report_fatal_error()` instead of `assert()` for the ad-hoc
error handling in two unittests. This reduces unnecessary differences
between release and debug builds (motivated by unused variable warnings
triggered in release builds).
llvm-svn: 304814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.
No other change was made. I did no manual edits, all of this is
clang-format.
This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.
llvm-svn: 304786
|
|
|
|
| |
llvm-svn: 304778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same basic block.
Summary:
This problem stems from the fact that instructions are allocated using new
in LLVM, i.e. there is no relationship that can be derived by just looking
at the pointer value.
This interface dispatches to appropriate dominance check given 2 instructions,
i.e. in case the instructions are in the same basic block, ordered basicblock
(with instruction numbering and caching) are used. Otherwise, dominator tree
is used.
This is a preparation patch for https://reviews.llvm.org/D32720
Reviewers: dberlin, hfinkel, davide
Subscribers: davide, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D33380
llvm-svn: 304764
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing .mir files immediately construct the MachineFunctions and
put them into MachineModuleInfo.
This allows us to get rid of the delayed construction (and delayed error
reporting) through the MachineFunctionInitialzier interface.
Differential Revision: https://reviews.llvm.org/D33809
llvm-svn: 304758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a quadratic behavior in assert-enabled builds.
GVN propagates the equivalence from a condition into the blocks guarded by the
condition. E.g. for 'if (a == 7) { ... }', 'a' will be replaced in the block
with 7. It does this by replacing all the uses of 'a' that are dominated by
the true edge.
For a switch with N cases and U uses of the value, this will mean N * U calls
to 'dominates'. Asserting isSingleEdge in 'dominates' make this N^2 * U
because this function checks for the uniqueness of the edge. I.e. traverses
each edge between the SwitchInst's block and the cases.
The change removes the assert and makes 'dominates' works correctly in the
presence of non-unique edges.
This brings build time down by an order of magnitude for an input that has
~10k cases in a switch statement.
Differential Revision: https://reviews.llvm.org/D33584
llvm-svn: 304721
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Matches C++ destruction ordering better and fixes possible problems of loaded libraries having inter-dependencies.
Reviewers: efriedma, v.g.vassilev, chapuni
Reviewed By: efriedma
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D33652
llvm-svn: 304720
|
|
|
|
|
|
| |
wrapped set.
llvm-svn: 304695
|
|
|
|
| |
llvm-svn: 304694
|
|
|
|
| |
llvm-svn: 304693
|
|
|
|
| |
llvm-svn: 304677
|
|
|
|
| |
llvm-svn: 304676
|
|
|
|
|
|
|
| |
SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the
environment.
llvm-svn: 304670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously MappedBlockStream owned its own BumpPtrAllocator that
it would allocate from when a read crossed a block boundary. This
way it could still return the user a contiguous buffer of the
requested size. However, It's not uncommon to open a stream, read
some stuff, close it, and then save the information for later.
After all, since the entire file is mapped into memory, the data
should always be available as long as the file is open.
Of course, the exception to this is when the data isn't *in* the
file, but rather in some buffer that we temporarily allocated to
present this contiguous view. And this buffer would get destroyed
as soon as the strema was closed.
The fix here is to force the user to specify the allocator, this
way it can provide an allocator that has whatever lifetime it
chooses.
Differential Revision: https://reviews.llvm.org/D33858
llvm-svn: 304623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This might give a few better opportunities to optimize these to memcpy
rather than loops - also a few minor cleanups (StringRef-izing,
templating (to avoid std::function indirection), etc).
The SmallVector::assign(iter, iter) could be improved with the use of
SFINAE, but the (iter, iter) ctor and append(iter, iter) need it to and
don't have it - so, workaround it for now rather than bothering with the
added complexity.
(also, as noted in the added FIXME, these assign ops could potentially
be optimized better at least for non-trivially-copyable types)
llvm-svn: 304566
|
|
|
|
|
|
|
| |
So far it would return true for the first uncached query, then cached
queries return false.
llvm-svn: 304545
|
|
|
|
|
|
|
|
| |
This was rL304226, reverted in 304228 due to a clang assertion failure
on the build bots. That problem should have been addressed by clang
commit rL304470.
llvm-svn: 304488
|
|
|
|
|
|
|
| |
As discussed in
http://lists.llvm.org/pipermail/llvm-dev/2017-May/113525.html
llvm-svn: 304390
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent of the test is to check that array lengths greater than
UINT_MAX work properly. Change the test to stress that scenario, without
triggering pointer overflow UB.
Caught by a WIP pointer overflow checker in clang.
Differential Revision: https://reviews.llvm.org/D33149
llvm-svn: 304353
|
|
|
|
|
|
|
|
| |
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D33627
llvm-svn: 304300
|
|
|
|
|
|
| |
At least one build bot is complaining. Will investigate after lunch.
llvm-svn: 304228
|