Notably, just close two of the debug info metadata nodes early rather
than leaving them open with `...` which won't ever lex correctly. And
add the missing `:` on the count labels.
Slowly progressing through all of the warnings on the documentation
build bot. Sorry to do this one commit at a time, but despite my best
efforts I can't trigger these errors locally.
llvm-svn: 338982
Sphinx syntax highlighter.
This example also doesn't really make sense. There is no control flow or
clarification of what the `Safe:` block exists to do... If we want
examples here, we should make them much more clear in addition to making
them well formed IR sequences.
llvm-svn: 338981
This appears to produce a warning on the docs build bot. It doesn't
reproduce for me, likely because I have a newer (or more full featured)
pygments install.
llvm-svn: 338978
Sphinx.
We think the bot is updated now, so trying this again. I'm landing it
(with permission) as Michael is at a con at the moment.
Actual patch largely by Michael Spencer.
Differential Revision: https://reviews.llvm.org/D44910
llvm-svn: 338977
Summary:
We already have the same check directly before, so this code can never be
reached (as seen in the test coverage).
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50317
llvm-svn: 338976
This code was moved out from BasicObjectLayerMaterializationUnit, which required
the supplied object to be well formed. The getObjectSymbolFlags function does
not require a well-formed object, so we have to propagate the error here.
llvm-svn: 338975
Summary:
Optimization remark format is slightly changed by LLVM patch D49412.
Two tests are fixed with expected messages changed.
Frankly speaking I have not tested this change yet. I will test when manage to setup the project.
Reviewers: xbolva00
Reviewed By: xbolva00
Subscribers: mehdi_amini, eraman, steven_wu, dexonsmith
Differential Revision: https://reviews.llvm.org/D50241
llvm-svn: 338971
Summary:
Optimization remark format is slightly changed by LLVM patch D49412.
One test is fixed with expected messages changed.
Frankly speaking I have not tested this change yet. I will test when manage to setup the project.
Reviewers: xbolva00, espindola
Reviewed By: xbolva00
Subscribers: emaste, arichardson, steven_wu, dexonsmith
Differential Revision: https://reviews.llvm.org/D50242
llvm-svn: 338970
Summary:
This patch improves Inliner to provide causes/reasons for negative inline decisions.
1. It adds one new message field to InlineCost to report causes for Always and Never instances. All Never and Always instantiations must provide a simple message.
2. Several functions that used to return the inlining results as boolean are changed to return InlineResult which carries the cause for negative decision.
3. Changed remark priniting and debug output messages to provide the additional messages and related inline cost.
4. Adjusted tests for changed printing.
Patch by: yrouban (Yevgeny Rouban)
Reviewers: craig.topper, sammccall, sgraenitz, NutshellySima, shchenz, chandlerc, apilipenko, javed.absar, tejohnson, dblaikie, sanjoy, eraman, xbolva00
Reviewed By: tejohnson, xbolva00
Subscribers: xbolva00, llvm-commits, arsenm, mehdi_amini, eraman, haicheng, steven_wu, dexonsmith
Differential Revision: https://reviews.llvm.org/D49412
llvm-svn: 338969
There are a bunch of edge cases and inconsistencies in how we're emitting sections
cause this warning to fire and it needs more work.
This reverts commit r335558.
llvm-svn: 338968
https://rise4fun.com/Alive/IT3
Comes up in the [most ugliest] signed int -> signed char case of
-fsanitize=implicit-conversion (https://reviews.llvm.org/D50250)
Not sure if we want to do it always, or only when it is free to invert.
llvm-svn: 338967
These forward declarations for various classes in the Type
hierarchy are not needed since they are all forward declared
systematically a few lines below.
llvm-svn: 338966
Looks like the only reason we use a unique_ptr here is so that we can
conditionally construct a LogicalErrorHandler. It's a small type, and
Optional can do the same thing with 100% fewer heap allocations.
llvm-svn: 338962
This allows us to model the common LLVM idiom of incrementing
immediately after dereferencing so that we can remove or update the
entity w/o losing our ability to reach the "next".
However, these are not real or proper iterators. They are just enough to
allow range based for loops and very simple range algorithms to work,
but should not be considered full general.
Differential Revision: https://reviews.llvm.org/D49956
llvm-svn: 338955
Summary:
Previously, in the NewPM pipeline, TailCallElim recalculates the DomTree when it modifies any instruction in the Function.
For example,
```
CallInst *CI = dyn_cast<CallInst>(&I);
...
CI->setTailCall();
Modified = true;
...
if (!Modified || ...)
return PreservedAnalyses::all();
```
After applying this patch, the DomTree only recalculates if needed (plus an extra insertEdge() + an extra deleteEdge() call).
When optimizing SQLite with `-passes="default<O3>"` pipeline of the newPM, the number of DomTree recalculation decreases by 6.2%, the number of nodes visited by DFS decreases by 2.9%. The time used by DomTree will decrease approximately 1%~2.5% after applying the patch.
Statistics:
```
Before the patch:
23010 dom-tree-stats - Number of DomTree recalculations
489264 dom-tree-stats - Number of nodes visited by DFS -- DomTree
After the patch:
21581 dom-tree-stats - Number of DomTree recalculations
475088 dom-tree-stats - Number of nodes visited by DFS -- DomTree
```
Reviewers: kuhar, dmgreen, brzycki, grosser, davide
Reviewed By: kuhar, brzycki
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49982
llvm-svn: 338954
This simplifies the code a bit.
It is NFC except that it removes early exit for Count == 0
which does not seem to be useful (we have no such tests either).
Differential revision: https://reviews.llvm.org/D49136
llvm-svn: 338953
I noticed a suspicious failure:
[ RUN ] VMRange.CollectionContains
llvm/src/tools/lldb/unittests/Utility/VMRangeTest.cpp:146: Failure
Value of: VMRange::ContainsRange(collection, VMRange(0x100, 0x104))
Actual: false
Expected: true
Looking at the code, it is a very real bug:
class RangeInRangeUnaryPredicate {
public:
RangeInRangeUnaryPredicate(VMRange range) : _range(range) {} // note that _range binds to a temporary!
bool operator()(const VMRange &range) const {
return range.Contains(_range);
}
const VMRange &_range;
};
This change fixes the bug.
Differential Revision: https://reviews.llvm.org/D50290
llvm-svn: 338949
When a non-extended temporary object is created in a conditional branch, the
lifetime of that temporary ends outside the conditional (at the end of the
full-expression). If we're inserting lifetime markers, this means we could end
up generating
if (some_cond) {
lifetime.start(&tmp);
Tmp::Tmp(&tmp);
}
// ...
if (some_cond) {
lifetime.end(&tmp);
}
... for a full-expression containing a subexpression of the form `some_cond ?
Tmp().x : 0`. This patch moves the lifetime start for such a temporary out of
the conditional branch so that we don't need to generate an additional basic
block to hold the lifetime end marker.
This is disabled if we want precise lifetime markers (for asan's
stack-use-after-scope checks) or of the temporary has a non-trivial destructor
(in which case we'd generate an extra basic block anyway to hold the destructor
call).
Differential Revision: https://reviews.llvm.org/D50286
llvm-svn: 338945
Summary:
Added corpus of arrays to use as inputs for the functions. Check that the two
functions modify the inputted arrays in the same way.
Reviewers: kcc, morehouse
Reviewed By: morehouse
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D50194
llvm-svn: 338943
__builtin_memmove (in non-type-punning cases).
This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.
__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.
This reinstates r338455, reverted in r338602, with a fix to avoid trying
to constant-evaluate a memcpy call if either pointer operand has an
invalid designator.
llvm-svn: 338941
This change allows users pass compression level that was not listed
in the enum. Also, I think using different values than zlib's
compression levels was just confusing.
Differential Revision: https://reviews.llvm.org/D50196
llvm-svn: 338939
This matches the behavior of the ELF linker where -u/--undefined
means symbols will get pulled in from archives but won't result
in link error if they are missing.
Also, don't actually great symbol table entries for the undefined
symbols, again matching more closely the ELF linker.
This also results in simplification of the code.
Differential Revision: https://reviews.llvm.org/D50279
llvm-svn: 338938
Some of Apple's public CI nodes ship an lldb which has trouble debugging
the asan-deque.cpp test. Specifically, that lldb appears to either parse
location lists in the test program incorrectly or to have a broken
std::deque data formatter.
We don't want to work around this by weakening the integration test, and
we're unable to update the lldb version on the CI node at the moment.
The compromise is to require AppleLLDB >= 1000 when AppleLLDB is being
used to debug this test.
Reviewed (in person) by Adrian Prantl.
Bot failure:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA/48074
rdar://42892721
llvm-svn: 338937
Libc++ needs to know when aligned allocation is supported by clang, but is
otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up
generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with
alignment arguments.
This patch implements the following changes:
* The `__cpp_aligned_new` feature test macro to no longer be defined when
aligned allocation is otherwise enabled but unavailable.
* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the
user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.
* Instead of a warning Clang now generates a hard error when an aligned
allocation or deallocation function is referenced but unavailable.
Patch by Eric Fiselier.
Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith
Reviewed By: rsmith
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45015
llvm-svn: 338934
