| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 338522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAG combiner logic to simplify AND masks in shift counts is invalid.
While it is true that the SystemZ shift instructions ignore all but the
low 6 bits of the shift count, it is still invalid to simplify the AND
masks while the DAG still uses the standard shift operators (which are
*not* defined to match the SystemZ instruction behavior).
Instead, this patch performs equivalent operations during instruction
selection. For completely removing the AND, this now happens via
additional DAG match patterns implemented by a multi-alternative
PatFrags. For simplifying a 32-bit AND to a 16-bit AND, the existing DAG
patterns were already mostly OK, they just needed an output XForm to
actually truncate the immediate value.
Unfortunately, the latter change also exposed a bug in TableGen: it
seems XForms are currently only handled correctly for direct operands of
the outermost operation node. This patch also fixes that bug by simply
recurring through the whole pattern. This should be NFC for all other
targets.
Differential Revision: https://reviews.llvm.org/D50096
llvm-svn: 338521
|
|
|
|
| |
llvm-svn: 338520
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: acoomans, cfe-commits
Differential Revision: https://reviews.llvm.org/D50138
llvm-svn: 338519
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
That way, as soon as the "initialize" is received by the server, it can start
parsing/indexing with a valid compilation database and not have to wait for a
an initial 'didChangeConfiguration' that might or might not happen.
Then, when the user changes configuration, a didChangeConfiguration can be sent.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: malaperle
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D49833
llvm-svn: 338518
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The implicit bool conversion could happen superisingly, e.g. when
checking `if (Loc1 == Loc2)`, the compiler will convert SymbolLocation to
bool before comparing (because we don't define operator `==` for SymbolLocation).
Reviewers: sammccall
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D49657
llvm-svn: 338517
|
|
|
|
| |
llvm-svn: 338516
|
|
|
|
| |
llvm-svn: 338514
|
|
|
|
| |
llvm-svn: 338513
|
|
|
|
|
|
|
|
| |
The latest version of the isl C++ bindings does not export the 'set'
method yet. Fall back to the C interface until this method can be
exported.
llvm-svn: 338512
|
|
|
|
|
|
|
|
| |
Should fix the MSVC bots by explicitly invoking
llvm::make_reverse_iterator to remove ambiguity with
std::make_reverse_iterator.
llvm-svn: 338511
|
|
|
|
| |
llvm-svn: 338510
|
|
|
|
|
|
|
| |
Follow-up for r338506 with some unrelated changes in formatting and
consistency.
llvm-svn: 338509
|
|
|
|
| |
llvm-svn: 338508
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49243
llvm-svn: 338507
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DWARFDie is a lightweight utility wrapper that stores a pointer to a
compile unit and a debug info entry. Currently, its iterator (used for
walking over its children) stores a DWARFDie and returns a const
reference when dereferencing it.
When the iterator is modified (by incrementing or decrementing it), this
reference becomes invalid. This was happening when calling reverse on
it, because the std::reverse_iterator is keeping a temporary copy of the
iterator (see
https://en.cppreference.com/w/cpp/iterator/reverse_iterator for a good
illustration).
The relevant code in libcxx:
reference operator*() const {_Iter __tmp = current; return *--__tmp;}
When dereferencing the reverse iterator, we decrement and return a
reference to a DWARFDie stored in the stack frame of this function,
resulting in UB at runtime.
This patch specifies the std::reverse_iterator for DWARFDie to do the
right thing.
Differential revision: https://reviews.llvm.org/D49679
llvm-svn: 338506
|
|
|
|
|
|
|
|
|
|
| |
These namespace qualifiers are not needed. Dropping them brings us
closer to the official isl namespace qualifiers.
While the delta of this change set is large, it only mechanically drops
the 'isl::' prefixes.
llvm-svn: 338505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main difference in this change is that isl_stat is now always
checked by default. As we elminiated most used of isl_stat, thanks to
Philip Pfaffe's implementation of foreach, only a small set of changes
is needed.
This change does not include the following recent changes to isl's C++
bindings:
- stricter error handling for isl_bool
- dropping of the isl::namespace qualifiers
The former requires a larger patch in Polly and consequently should go
through a patch-review. The latter will be applied in the next commit to
keep this commit free from noise.
We also still apply a couple of other changes on top of the official isl
bindings. This delta is expected to shrink over time.
llvm-svn: 338504
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Clang emits error when implicit modules was relocated from the
first build directory. However this was biting our usecase where we copy
the contents of build directory to another directory in order to
distribute.
Differential Revision: https://reviews.llvm.org/D49852
llvm-svn: 338503
|
|
|
|
| |
llvm-svn: 338502
|
|
|
|
| |
llvm-svn: 338501
|
|
|
|
|
|
| |
Test for https://bugs.llvm.org/show_bug.cgi?id=38180.
llvm-svn: 338500
|
|
|
|
|
|
|
|
|
|
| |
Select G_GLOBAL_VALUE for position dependent code.
Patch by Petar Avramovic.
Differential Revision: https://reviews.llvm.org/D49803
llvm-svn: 338499
|
|
|
|
| |
llvm-svn: 338498
|
|
|
|
| |
llvm-svn: 338497
|
|
|
|
| |
llvm-svn: 338496
|
|
|
|
|
|
|
| |
This means it will be installed also in builds configured with
LLVM_INSTALL_TOOLCHAIN_ONLY, such as the Windows packages.
llvm-svn: 338495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 338494
|
|
|
|
|
|
|
|
| |
Also add a test for it being unsupported for linux.
Differential Revision: https://reviews.llvm.org/D49929
llvm-svn: 338493
|
|
|
|
|
|
|
|
|
|
| |
(CTTZ X), -1, (X != 0)), C), make sure we really have a compare with 0.
It's not strictly required by the transform of the cmov and the add, but it makes sure we restrict it to the cases we know we want to match.
While there canonicalize the operand order of the cmov to simplify the matching and emitting code.
llvm-svn: 338492
|
|
|
|
|
|
|
|
| |
The suspicious behavior is obviously because this method reads
OOB memory, so I'll remove it for now and re-add the test alongside
the fix later.
llvm-svn: 338491
|
|
|
|
|
|
|
|
|
| |
GCC 4.8.5 defaults to this old C standard. I think we should make the
tests pass a newer -std=c99|c11 but that's too intrusive for now...
Differential Revision: https://reviews.llvm.org/D50084
llvm-svn: 338490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
rC337815 / D49508 had to cannibalize one bit of `CastExprBitfields::BasePathSize` in order to squeeze `PartOfExplicitCast` boolean.
That reduced the maximal value of `PartOfExplicitCast` from 9 bits (~512) down to 8 bits (~256).
Apparently, that mattered. Too bad there weren't any tests.
It caused [[ https://bugs.llvm.org/show_bug.cgi?id=38356 | PR38356 ]].
So we need to increase `PartOfExplicitCast` back at least to 9 bits, or a bit more.
For obvious reasons, we can't do that in `CastExprBitfields` - that would blow up the size of every `Expr`.
So we need to either just add a variable into the `CastExpr` (as done here),
or use `llvm::TrailingObjects`. The latter does not seem to be straight-forward.
Perhaps, that needs to be done not for the `CastExpr` itself, but for all of it's `final` children.
Reviewers: rjmccall, rsmith, erichkeane
Reviewed By: rjmccall
Subscribers: bricci, hans, cfe-commits, waddlesplash
Differential Revision: https://reviews.llvm.org/D50050
llvm-svn: 338489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds an initial small unit test for LLDB's Stream class, which should at least cover
most of the functions in the Stream class. StreamString is always in big endian
mode, so that's the only stream byte order path this test covers as of now. Also,
the binary mode still needs to be tested for all print methods.
Also adds some FIXMEs for wrong/strange result values of the Stream class that we hit
while testing those functions.
Reviewers: labath
Reviewed By: labath
Subscribers: probinson, labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50027
llvm-svn: 338488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This revision implements support for generating DWARFv5 .debug_addr section.
The implementation is pretty straight-forward: we just check the dwarf version
and emit section header if needed.
Reviewers: aprantl, dblaikie, probinson
Reviewed by: dblaikie
Differential Revision: https://reviews.llvm.org/D50005
llvm-svn: 338487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- fix a stupid unit test typo
- add <charconv> symbols to Linux abilist
Reviewers: EricWF
Subscribers: christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D50130
llvm-svn: 338486
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch intends to enable jump threading when a method whose return type is std::pair<int, bool> or std::pair<bool, int> is inlined.
For example, jump threading does not happen for the if statement in func.
std::pair<int, bool> callee(int v) {
int a = dummy(v);
if (a) return std::make_pair(dummy(v), true);
else return std::make_pair(v, v < 0);
}
int func(int v) {
std::pair<int, bool> rc = callee(v);
if (rc.second) {
// do something
}
SROA executed before the method inlining replaces std::pair by i64 without splitting in both callee and func since at this point no access to the individual fields is seen to SROA.
After inlining, jump threading fails to identify that the incoming value is a constant due to additional instructions (like or, and, trunc).
This series of patch add patterns in InstructionSimplify to fold extraction of members of std::pair. To help jump threading, actually we need to optimize the code sequence spanning multiple BBs.
These patches does not handle phi by itself, but these additional patterns help NewGVN pass, which calls instsimplify to check opportunities for simplifying instructions over phi, apply phi-of-ops optimization to result in successful jump threading.
SimplifyDemandedBits in InstCombine, can do more general optimization but this patch aims to provide opportunities for other optimizers by supporting a simple but common case in InstSimplify.
This first patch in the series handles code sequences that merges two values using shl and or and then extracts one value using lshr.
Differential Revision: https://reviews.llvm.org/D48828
llvm-svn: 338485
|
|
|
|
|
|
| |
Only generate symbol difference expression if needed.
llvm-svn: 338484
|
|
|
|
|
|
|
|
| |
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50128
llvm-svn: 338483
|
|
|
|
|
|
|
|
|
|
|
| |
Tests added in r338294 implicitly assume that libgcc is the runtime library,
but that's not the case when the user configures Clang to use compiler-rt in
which case these tests will break. Explicitly request libgcc when invoking
clang in these tests to avoid that.
Differential Revision: https://reviews.llvm.org/D50123
llvm-svn: 338482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EFLAGS copy lowering.
If you have a branch of LLVM, you may want to cherrypick this. It is
extremely unlikely to hit this case empirically, but it will likely
manifest as an "impossible" branch being taken somewhere, and will be
... very hard to debug.
Hitting this requires complex conditions living across complex control
flow combined with some interesting memory (non-stack) initialized with
the results of a comparison. Also, because you have to arrange for an
EFLAGS copy to be in *just* the right place, almost anything you do to
the code will hide the bug. I was unable to reduce anything remotely
resembling a "good" test case from the place where I hit it, and so
instead I have constructed synthetic MIR testing that directly exercises
the bug in question (as well as the good behavior for completeness).
The issue is that we would mistakenly assume any SETcc with a valid
condition and an initial operand that was a register and a virtual
register at that to be a register *defining* SETcc...
It isn't though....
This would in turn cause us to test some other bizarre register,
typically the base pointer of some memory. Now, testing this register
and using that to branch on doesn't make any sense. It even fails the
machine verifier (if you are running it) due to the wrong register
class. But it will make it through LLVM, assemble, and it *looks*
fine... But wow do you get a very unsual and surprising branch taken in
your actual code.
The fix is to actually check what kind of SETcc instruction we're
dealing with. Because there are a bunch of them, I just test the
may-store bit in the instruction. I've also added an assert for sanity
that ensure we are, in fact, *defining* the register operand. =D
llvm-svn: 338481
|
|
|
|
|
|
|
|
|
|
|
| |
we aren't incorrectly generating any of it when doing SLH.
There was a bug that only occured with SLH that very much looked like it
could be caused by bad unwind info, and so this was a prime suspect.
Turns out that everything is fine, but this way we'll *see* if we end
up, for example, putting things we shouldn't inside the prolog.
llvm-svn: 338480
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Major QoI considerations:
- The facility is backported to C++14, same as libstdc++.
- Efforts have been made to minimize the header dependencies.
- The design is friendly to the uses of MSVC intrinsics (`__emulu`, `_umul128`, `_BitScanForward`, `_BitScanForward64`) but not implemented; future contributions are welcome.
Thanks to Milo Yip for contributing the implementation of `__u64toa` and `__u32toa`.
References:
https://wg21.link/p0067r5
https://wg21.link/p0682r1
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: ldionne, Quuxplusone, christof, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D41458
llvm-svn: 338479
|
|
|
|
|
|
| |
See gcc.gnu.org/PR86769 for details of the bug.
llvm-svn: 338478
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is necessary to generate fixups in .debug_line as relaxation is
enabled due to the address delta may be changed after relaxation.
DWARF will record the mappings of lines and addresses in
.debug_line section. It will encode the information using special
opcodes, standard opcodes and extended opcodes in Line Number
Program. I use DW_LNS_fixed_advance_pc to encode fixed length
address delta and DW_LNE_set_address to encode absolute address
to make it possible to generate fixups in .debug_line section.
Differential Revision: https://reviews.llvm.org/D46850
llvm-svn: 338477
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were just visiting the blocks in the function in IR order, which
is rather arbitrary. Therefore we wouldn't always visit defs before uses, but
the translation code relies on this assumption in some places.
Only codegen change seen in tests is an elision of a redundant copy.
Fixes PR38396
llvm-svn: 338476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_LIBCPP_BUILDING_LIBRARY
Summary: As suggested by Marshall in https://reviews.llvm.org/D49914
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50008
llvm-svn: 338475
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newly added methods allow reasoning about the stack frame of the call (as
opposed to the stack frame on which the call was made, which was always
available) - obtain the stack frame context, obtain parameter regions - even if
the call is not going to be (or was not) inlined, i.e. even if the analysis
has never actually entered the stack frame.
Differential Revision: https://reviews.llvm.org/D49715
llvm-svn: 338474
|
|
|
|
| |
llvm-svn: 338473
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a node handle type, (located in __node_handle), and adds
extract() and insert() members to all map and set types, as well as their
implementations in __tree and __hash_table.
The second half of this feature is adding merge() members, which splice nodes
in bulk from one container into another. This will be committed in a follow-up.
Differential revision: https://reviews.llvm.org/D46845
llvm-svn: 338472
|