Martin Storsjo [Wed, 25 Jul 2018 19:01:36 +0000 (19:01 +0000)]
Add missing 'override', fixing compilation with some compilers since SVN r337950
llvm-svn: 337952
Martin Storsjo [Wed, 25 Jul 2018 18:35:42 +0000 (18:35 +0000)]
[COFF] Use comdat shared constants for MinGW as well
GNU binutils tools have no problems with this kind of shared constants,
provided that we actually hook it up completely in AsmPrinter and
produce a global symbol.
This effectively reverts SVN r335918 by hooking the rest of it up
properly.
This feature was implemented originally in SVN r213006, with no reason
for why it can't be used for MinGW other than the fact that GCC doesn't
do it while MSVC does.
Differential Revision: https://reviews.llvm.org/D49646
llvm-svn: 337951
Martin Storsjo [Wed, 25 Jul 2018 18:35:31 +0000 (18:35 +0000)]
[COFF] Hoist constant pool handling from X86AsmPrinter into AsmPrinter
In SVN r334523, the first half of comdat constant pool handling was
hoisted from X86WindowsTargetObjectFile (which despite the name only
was used for msvc targets) into the arch independent
TargetLoweringObjectFileCOFF, but the other half of the handling was
left behind in X86AsmPrinter::GetCPISymbol.
With only half of the handling in place, inconsistent comdat
sections/symbols are created, causing issues with both GNU binutils
(avoided for X86 in SVN r335918) and with the MS linker, which
would complain like this:
fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x4
Differential Revision: https://reviews.llvm.org/D49644
llvm-svn: 337950
Max Moroz [Wed, 25 Jul 2018 18:34:20 +0000 (18:34 +0000)]
[libFuzzer] Disable handle-unstable.test for ARM and delete duplicated test file.
Summary:
This change should fix the failures mentioned in
https://reviews.llvm.org/D49684#1175245
Reviewers: kevinwkt, morehouse, metzman
Reviewed By: kevinwkt, morehouse
Subscribers: kristof.beyls, delcypher, chrib, #sanitizers, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D49810
llvm-svn: 337949
Mikhail R. Gadelha [Wed, 25 Jul 2018 18:26:50 +0000 (18:26 +0000)]
[analyzer] Fix compilation when LLVM_ENABLE_MODULES=ON
llvm-svn: 337948
Eli Friedman [Wed, 25 Jul 2018 18:26:38 +0000 (18:26 +0000)]
[LangRef] Clarify undefined behavior for function attributes.
Violating the invariants specified by attributes is undefined behavior.
Maybe we could use poison instead for some of the parameter attributes,
but I don't think it's worthwhile.
Differential Revision: https://reviews.llvm.org/D49041
llvm-svn: 337947
Martin Storsjo [Wed, 25 Jul 2018 18:24:23 +0000 (18:24 +0000)]
[windows] Fix warning about comparing ints of different signs
This fixes a warning like this:
warning: comparison of integers of different signs:
'std::__1::__libcpp_tls_key' (aka 'long') and 'DWORD'
(aka 'unsigned long') [-Wsign-compare]
if (*__key == FLS_OUT_OF_INDEXES)
~~~~~~ ^ ~~~~~~~~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D49782
llvm-svn: 337946
Eli Friedman [Wed, 25 Jul 2018 18:22:22 +0000 (18:22 +0000)]
[ARM] Prefer lsls+lsrs over lsls+ands or lsrs+ands in Thumb1.
Saves materializing the immediate for the "ands".
Corresponding patterns exist for lsrs+lsls, but that seems less common
in practice.
Now implemented as a DAGCombine.
Differential Revision: https://reviews.llvm.org/D49585
llvm-svn: 337945
Nick Desaulniers [Wed, 25 Jul 2018 18:11:01 +0000 (18:11 +0000)]
[clang:sema] de-duplicate getDepthAndIndex helpers
Summary:
Continuing off of:
https://reviews.llvm.org/D38382
Fixes:
https://bugs.llvm.org/show_bug.cgi?id=12176
Reviewers: srhines, pirama, vsk
Reviewed By: vsk
Subscribers: cfe-commits, vsk, maitesin
Differential Revision: https://reviews.llvm.org/D49760
llvm-svn: 337944
Roman Tereshin [Wed, 25 Jul 2018 18:01:41 +0000 (18:01 +0000)]
[SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform
as well as sext(C + x + ...) -> (D + sext(C-D + x + ...))<nuw><nsw>
similar to the equivalent transformation for zext's
if the top level addition in (D + (C-D + x * n)) could be proven to
not wrap, where the choice of D also maximizes the number of trailing
zeroes of (C-D + x * n), ensuring homogeneous behaviour of the
transformation and better canonicalization of such AddRec's
(indeed, there are 2^(2w) different expressions in `B1 + ext(B2 + Y)` form for
the same Y, but only 2^(2w - k) different expressions in the resulting `B3 +
ext((B4 * 2^k) + Y)` form, where w is the bit width of the integral type)
This patch generalizes sext(C1 + C2*X) --> sext(C1) + sext(C2*X) and
sext{C1,+,C2} --> sext(C1) + sext{0,+,C2} transformations added in
r209568 relaxing the requirements the following way:
1. C2 doesn't have to be a power of 2, it's enough if it's divisible by 2
a sufficient number of times;
2. C1 doesn't have to be less than C2, instead of extracting the entire
C1 we can split it into 2 terms: (00...0XXX + YY...Y000), keep the
second one that may cause wrapping within the extension operator, and
move the first one that doesn't affect wrapping out of the extension
operator, enabling further simplifications;
3. C1 and C2 don't have to be positive, splitting C1 like shown above
produces a sum that is guaranteed to not wrap, signed or unsigned;
4. in AddExpr case there could be more than 2 terms, and in case of
AddExpr the 2nd and following terms and in case of AddRecExpr the
Step component don't have to be in the C2*X form or constant
(respectively), they just need to have enough trailing zeros,
which in turn could be guaranteed by means other than arithmetics,
e.g. by a pointer alignment;
5. the extension operator doesn't have to be a sext, the same
transformation works and profitable for zext's as well.
Apparently, optimizations like SLPVectorizer currently fail to
vectorize even rather trivial cases like the following:
double bar(double *a, unsigned n) {
double x = 0.0;
double y = 0.0;
for (unsigned i = 0; i < n; i += 2) {
x += a[i];
y += a[i + 1];
}
return x * y;
}
If compiled with `clang -std=c11 -Wpedantic -Wall -O3 main.c -S -o - -emit-llvm`
(!{!"clang version 7.0.0 (trunk 337339) (llvm/trunk 337344)"})
it produces scalar code with the loop not unrolled with the unsigned `n` and
`i` (like shown above), but vectorized and unrolled loop with signed `n` and
`i`. With the changes made in this commit the unsigned version will be
vectorized (though not unrolled for unclear reasons).
How it all works:
Let say we have an AddExpr that looks like (C + x + y + ...), where C
is a constant and x, y, ... are arbitrary SCEVs. Let's compute the
minimum number of trailing zeroes guaranteed of that sum w/o the
constant term: (x + y + ...). If, for example, those terms look like
follows:
i
XXXX...X000
YYYY...YY00
...
ZZZZ...0000
then the rightmost non-guaranteed-zero bit (a potential one at i-th
position above) can change the bits of the sum to the left (and at
i-th position itself), but it can not possibly change the bits to the
right. So we can compute the number of trailing zeroes by taking a
minimum between the numbers of trailing zeroes of the terms.
Now let's say that our original sum with the constant is effectively
just C + X, where X = x + y + .... Let's also say that we've got 2
guaranteed trailing zeros for X:
j
CCCC...CCCC
XXXX...XX00 // this is X = (x + y + ...)
Any bit of C to the left of j may in the end cause the C + X sum to
wrap, but the rightmost 2 bits of C (at positions j and j - 1) do not
affect wrapping in any way. If the upper bits cause a wrap, it will be
a wrap regardless of the values of the 2 least significant bits of C.
If the upper bits do not cause a wrap, it won't be a wrap regardless
of the values of the 2 bits on the right (again).
So let's split C to 2 constants like follows:
0000...00CC = D
CCCC...CC00 = (C - D)
and represent the whole sum as D + (C - D + X). The second term of
this new sum looks like this:
CCCC...CC00
XXXX...XX00
----------- // let's add them up
YYYY...YY00
The sum above (let's call it Y)) may or may not wrap, we don't know,
so we need to keep it under a sext/zext. Adding D to that sum though
will never wrap, signed or unsigned, if performed on the original bit
width or the extended one, because all that that final add does is
setting the 2 least significant bits of Y to the bits of D:
YYYY...YY00 = Y
0000...00CC = D
----------- <nuw><nsw>
YYYY...YYCC
Which means we can safely move that D out of the sext or zext and
claim that the top-level sum neither sign wraps nor unsigned wraps.
Let's run an example, let's say we're working in i8's and the original
expression (zext's or sext's operand) is 21 + 12x + 8y. So it goes
like this:
0001 0101 // 21
XXXX XX00 // 12x
YYYY Y000 // 8y
0001 0101 // 21
ZZZZ ZZ00 // 12x + 8y
0000 0001 // D
0001 0100 // 21 - D = 20
ZZZZ ZZ00 // 12x + 8y
0000 0001 // D
WWWW WW00 // 21 - D + 12x + 8y = 20 + 12x + 8y
therefore zext(21 + 12x + 8y) = (1 + zext(20 + 12x + 8y))<nuw><nsw>
This approach could be improved if we move away from using trailing
zeroes and use KnownBits instead. For instance, with KnownBits we could
have the following picture:
i
10 1110...0011 // this is C
XX X1XX...XX00 // this is X = (x + y + ...)
Notice that some of the bits of X are known ones, also notice that
known bits of X are interspersed with unknown bits and not grouped on
the rigth or left.
We can see at the position i that C(i) and X(i) are both known ones,
therefore the (i + 1)th carry bit is guaranteed to be 1 regardless of
the bits of C to the right of i. For instance, the C(i - 1) bit only
affects the bits of the sum at positions i - 1 and i, and does not
influence if the sum is going to wrap or not. Therefore we could split
the constant C the following way:
i
00 0010...0011 = D
10 1100...0000 = (C - D)
Let's compute the KnownBits of (C - D) + X:
XX1 1 = carry bit, blanks stand for known zeroes
10 1100...0000 = (C - D)
XX X1XX...XX00 = X
--- -----------
XX X0XX...XX00
Will this add wrap or not essentially depends on bits of X. Adding D
to this sum, however, is guaranteed to not to wrap:
0 X
00 0010...0011 = D
sX X0XX...XX00 = (C - D) + X
--- -----------
sX XXXX XX11
As could be seen above, adding D preserves the sign bit of (C - D) +
X, if any, and has a guaranteed 0 carry out, as expected.
The more bits of (C - D) we constrain, the better the transformations
introduced here canonicalize expressions as it leaves less freedom to
what values the constant part of ((C - D) + x + y + ...) can take.
Reviewed By: mzolotukhin, efriedma
Differential Revision: https://reviews.llvm.org/D48853
llvm-svn: 337943
Stella Stamenova [Wed, 25 Jul 2018 17:33:20 +0000 (17:33 +0000)]
[windows] Don't inline fieldFromInstruction on Windows
Summary:
The VS compiler (on Windows) has a bug which results in fieldFromInstruction being optimized out in some circumstances. This only happens in *release no debug info* builds that have assertions *turned off* - in all other situations the function is not inlined, so the functionality is correct. All of the bots have assertions turned on, so this path is not regularly tested. The workaround is to not inline the function on Windows - if the bug is fixed in a later release of the VS compiler, the noinline specification can be removed.
The test that consistently reproduces this is Lanai v11.txt test.
Reviewers: asmith, labath, zturner
Subscribers: dblaikie, stella.stamenova, aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D49753
llvm-svn: 337942
Alexey Bataev [Wed, 25 Jul 2018 17:27:45 +0000 (17:27 +0000)]
[OPENMP] Exclude service expressions/statements from the list of
the children.
Special internal helper expressions/statements for the OpenMP directives
should not be exposed as children, only the main substatement must be
represented as the child.
llvm-svn: 337941
Xinliang David Li [Wed, 25 Jul 2018 17:22:12 +0000 (17:22 +0000)]
Add an option to specify the name of
an function whose CFG is to be viewed/printed.
Differential Revision: https://reviews.llvm.org/D49447
llvm-svn: 337940
Ulrich Weigand [Wed, 25 Jul 2018 17:08:13 +0000 (17:08 +0000)]
Fix corruption of result number in LegalizeVectorOps.cpp
When VectorLegalizer::LegalizeOp creates a new SDValue after iterating
over its arguments, we need to refer to the same result number of the
new node that the original value used.
Reviewed by: cameron.mcinally
Differential Revision: https://reviews.llvm.org/D49805
llvm-svn: 337939
Stanislav Mekhanoshin [Wed, 25 Jul 2018 17:02:11 +0000 (17:02 +0000)]
[AMDGPU] Use AssumptionCacheTracker in the divrem32 expansion
Differential Revision: https://reviews.llvm.org/D49761
llvm-svn: 337938
Petr Hosek [Wed, 25 Jul 2018 16:51:00 +0000 (16:51 +0000)]
[CMake] Use LIBCXXABI_LIBDIR_SUFFIX in libc++abi build
This was changed unintentionally in r335809.
Differential Revision: https://reviews.llvm.org/D49765
llvm-svn: 337937
Stanislav Mekhanoshin [Wed, 25 Jul 2018 16:39:24 +0000 (16:39 +0000)]
Fix llvm::ComputeNumSignBits with some operations and llvm.assume
Currently ComputeNumSignBits does early exit while processing some
of the operations (add, sub, mul, and select). This prevents the
function from using AssumptionCacheTracker if passed.
Differential Revision: https://reviews.llvm.org/D49759
llvm-svn: 337936
Pavel Labath [Wed, 25 Jul 2018 16:34:43 +0000 (16:34 +0000)]
Revert "dwarfgen: Add support for generating the debug_str_offsets section, take 2"
This reverts commit r337933. The build error is fixed but the test now
fails on the darwin buildbots. Investigating...
llvm-svn: 337935
Krzysztof Parzyszek [Wed, 25 Jul 2018 16:20:59 +0000 (16:20 +0000)]
[Hexagon] Properly scale bit index when extracting elements from vNi1
For example v = <2 x i1> is represented as
bbbbaaaa in a predicate register,
where b = v[1], a = v[0]. Extracting v[1] is equivalent to extracting bit 4
from the predicate register.
llvm-svn: 337934
Pavel Labath [Wed, 25 Jul 2018 15:33:32 +0000 (15:33 +0000)]
dwarfgen: Add support for generating the debug_str_offsets section, take 2
This recommits r337910 after fixing an "ambiguous call to addAttribute"
error with some compilers (gcc circa 4.9 and MSVC). It seems that these
compilers will consider a "false -> pointer" conversion during overload
resolution. This creates ambiguity because one I added an overload which
takes a MCExpr * as an argument.
I fix this by making the new overload take MCExpr&, which avoids the
conversion. It also documents the fact that we expect a valid MCExpr
object.
Original commit message follows:
The motivation for this is D49493, where we'd like to test details of
debug_str_offsets behavior which is difficult to trigger from a
traditional test.
This adds the plubming necessary for dwarfgen to generate this section.
The more interesting changes are:
- I've moved emitStringOffsetsTableHeader function from DwarfFile to
DwarfStringPool, so I can generate the section header more easily from
the unit test.
- added a new addAttribute overload taking an MCExpr*. This is used to
generate the DW_AT_str_offsets_base, which links a compile unit to the
offset table.
I've also added a basic test for reading and writing DW_form_strx forms.
Reviewers: dblaikie, JDevlieghere, probinson
Subscribers: llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D49670
llvm-svn: 337933
Jonas Devlieghere [Wed, 25 Jul 2018 15:20:15 +0000 (15:20 +0000)]
[ProcessGDBRemote] handle result from ConnectToDebugserver
We ignored the result from ConnectToDebugserver, causing certain errors
(like a failed handshake) not to surface.
llvm-svn: 337932
Stefan Granitz [Wed, 25 Jul 2018 15:19:04 +0000 (15:19 +0000)]
Use LLVM's new ItaniumPartialDemangler in LLDB
Summary:
Replace the existing combination of FastDemangle and the fallback to llvm::itaniumDemangle() with LLVM's new ItaniumPartialDemangler. It slightly reduces complexity and slightly improves performance, but doesn't introduce conceptual changes. This patch is preparing for more fundamental improvements on LLDB's demangling approach.
Reviewers: friss, jingham, erik.pilkington, labath, clayborg, mgorny, davide, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: teemperor, JDevlieghere, labath, clayborg, davide, lldb-commits, mgorny, erik.pilkington
Differential Revision: https://reviews.llvm.org/D49612
llvm-svn: 337931
Andres Freund [Wed, 25 Jul 2018 15:04:57 +0000 (15:04 +0000)]
Move JIT listener C binding fallbackks to ExecutionEngineBindings.cpp.
Initially, in https://reviews.llvm.org/D44890, I had these defined as
empty functions inside the header when the respective event listener
was not built in. As done in that commit, that wasn't correct, because
it was a ODR violation. Krasimir hot-fixed that in r333265, but that
wasn't quite right either, because it'd lead to the symbol not being
available.
Instead just move the fallbacksto ExecutionEngineBindings.cpp. Could
define them as static inlines in the header too, but I don't think it
matters.
Reviewers: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49654
llvm-svn: 337930
Jeremy Morse [Wed, 25 Jul 2018 14:48:53 +0000 (14:48 +0000)]
[XRay tests] Don't filter test-critical calls
By default, xray filters events that takes less than 5uS from its log.
In this existing test, should printf complete very quickly this will
lead to test-critical function calls being filtered (i.e. print_parent_tid).
Given that we're not testing the filtering feature, disable it for this
test.
llvm-svn: 337929
Alexey Bataev [Wed, 25 Jul 2018 14:40:26 +0000 (14:40 +0000)]
[OPENMP] Fix PR38256: Fix locations of the artificial conditional op.
Fixed the source locations of the conditional op so that they don'r
crash coverage pass.
llvm-svn: 337928
David Carlier [Wed, 25 Jul 2018 14:27:14 +0000 (14:27 +0000)]
Fix tsan doc
llvm-svn: 337927
David Carlier [Wed, 25 Jul 2018 13:55:06 +0000 (13:55 +0000)]
[Docs] Update supported oses for safestack, ubsan, asan, tsan and msan
Adding oses others than Linux.
llvm-svn: 337926
Louis Dionne [Wed, 25 Jul 2018 13:40:49 +0000 (13:40 +0000)]
[NFC] Fix grammatical mistakes in libc++ FileTimeType design docs
llvm-svn: 337925
Pavel Labath [Wed, 25 Jul 2018 12:52:30 +0000 (12:52 +0000)]
Revert "dwarfgen: Add support for generating the debug_str_offsets section"
This reverts commit r337910 as it's generating "ambiguous call to
addAttribute" errors on some bots.
Will resubmit once I get a chance to look into the problem.
llvm-svn: 337924
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:47 +0000 (12:49 +0000)]
[analyzer] Use the macro REGISTER_TRAIT_WITH_PROGRAMSTATE in the Z3 backend
Summary:
The macro was manually expanded in the Z3 backend and this patch adds it back.
Adding the expanded code is dangerous as the macro may change in the future and the expanded code might be left outdated.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49769
llvm-svn: 337923
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:43 +0000 (12:49 +0000)]
[analyzer] Removed API used by the Refutation Manager from SMTConstraintManager and replace by proper calls to SMTSolver
Summary:
Third patch in the refactoring series, to decouple the SMT Solver from the Refutation Manager (1st: D49668, 2nd: D49767).
The refutation API in the `SMTConstraintManager` was a hack to allow us to create an SMT solver and verify the constraints; it was conceptually wrong from the start. Now, we don't actually need to use the `SMTConstraintManager` and can create an SMT object directly, add the constraints and check them.
While updating the Falsification visitor, I inlined the two functions that were used to collect the constraints and add them to the solver.
As a result of this patch, we could move the SMT API elsewhere and as it's not really dependent on the CSA anymore. Maybe we can create a new dir (utils/smt) for Z3 and future solvers?
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49768
llvm-svn: 337922
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:37 +0000 (12:49 +0000)]
[analyzer] Moved code from SMTConstraintManager to SMTSolver
Summary:
This is the second part of D49668, and moves all the code that's not specific to a ConstraintManager to SMTSolver.
No functional change intended.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49767
llvm-svn: 337921
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:32 +0000 (12:49 +0000)]
[analyzer] Try to minimize the number of equivalent bug reports evaluated by the refutation manager
Summary:
This patch changes how the SMT bug refutation runs in an equivalent bug report class.
Now, all other visitor are executed until they find a valid bug or mark all bugs as invalid. When the one valid bug is found (and crosscheck is enabled), the SMT refutation checks the satisfiability of this single bug.
If the bug is still valid after checking with Z3, it is returned and a bug report is created. If the bug is found to be invalid, the next bug report in the equivalent class goes through the same process, until we find a valid bug or all bugs are marked as invalid.
Massive speedups when verifying redis/src/rax.c, from 1500s to 10s.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49693
llvm-svn: 337920
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:29 +0000 (12:49 +0000)]
[analyzer] Moved non solver specific code from Z3ConstraintManager to SMTConstraintManager
Summary:
This patch moves a lot of code from `Z3ConstraintManager` to `SMTConstraintManager`, leaving only the necessary:
* `canReasonAbout` which returns if a Solver can handle a given `SVal` (should be moved to `SMTSolver` in the future).
* `removeDeadBindings`, `assumeExpr` and `print`: methods that need to use `ConstraintZ3Ty`, can probably be moved to `SMTConstraintManager` in the future.
The patch creates a new file, `SMTConstraintManager.cpp` with the moved code. Conceptually, this is move in the right direction and needs further improvements: `SMTConstraintManager` still does a lot of things that are not required by a `ConstraintManager`.
We ought to move the unrelated to `SMTSolver` and remove everything that's not related to a `ConstraintManager`. In particular, we could remove `addRangeConstraints` and `isModelFeasible`, and make the refutation manager create an Z3Solver directly.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: mgorny, xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49668
llvm-svn: 337919
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:23 +0000 (12:49 +0000)]
[analyzer] Implemented SMT generic API
Summary:
Created new SMT generic API.
Small changes to `Z3ConstraintManager` because of the new generic objects (`SMTSort` and `SMTExpr`) returned by `SMTSolver`.
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: mgorny, xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49495
llvm-svn: 337918
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:19 +0000 (12:49 +0000)]
[analyzer] Create generic SMT Expr class
Summary:
New base class for all future SMT Exprs.
No major changes except moving `areEquivalent` and `getFloatSemantics` outside of `Z3Expr` to keep the class minimal.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49551
llvm-svn: 337917
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:15 +0000 (12:49 +0000)]
[analyzer] Create generic SMT Sort Class
Summary:
New base class for all future SMT sorts.
The only change is that the class implements methods `isBooleanSort()`, `isBitvectorSort()` and `isFloatSort()` so it doesn't rely on `Z3`'s enum.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49550
llvm-svn: 337916
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:11 +0000 (12:49 +0000)]
[analyzer] Moved static Context to class member
Summary:
Although it is a big patch, the changes are simple:
1. There is one `Z3_Context` now, member of the `SMTConstraintManager` class.
2. `Z3Expr`, `Z3Sort`, `Z3Model` and `Z3Solver` are constructed with a reference to the `Z3_Context` in `SMTConstraintManager`.
3. All static functions are now members of `Z3Solver`, e.g, the `SMTConstraintManager` now calls `Solver.fromBoolean(false)` instead of `Z3Expr::fromBoolean(false)`.
Most of the patch only move stuff around except:
1. New method `Z3Sort MkSort(const QualType &Ty, unsigned BitWidth)`, that creates a sort based on the `QualType` and its width. Used to simplify the `fromData` method.
Unfortunate consequence of this patch:
1. `getInterpretation` was moved from `Z3Model` class to `Z3Solver`, because it needs to create a `Z3Sort` before returning the interpretation. This can be fixed by changing both `toAPFloat` and `toAPSInt` by removing the dependency of `Z3Sort` (it's only used to check which Sort was created and to retrieve the type width).
Reviewers: NoQ, george.karpenkov, ddcc
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49236
llvm-svn: 337915
Mikhail R. Gadelha [Wed, 25 Jul 2018 12:49:07 +0000 (12:49 +0000)]
[analyzer] Create generic SMT Context class
Summary:
This patch creates `SMTContext` which will wrap a specific SMT context, through `SMTSolverContext`.
The templated `SMTSolverContext` class it's a simple wrapper around a SMT specific context (currently only used in the Z3 backend), while `Z3Context` inherits `SMTSolverContext<Z3_context>` and implements solver specific operations like initialization and destruction of the context.
This separation was done because:
1. We might want to keep one single context, shared across different `SMTConstraintManager`s. It can be achieved by constructing a `SMTContext`, through a function like `CreateSMTContext(Z3)`, `CreateSMTContext(BOOLECTOR)`, etc. The rest of the CSA only need to know about `SMTContext`, so maybe it's a good idea moving `SMTSolverContext` to a separate header in the future.
2. Any generic SMT operation will only require one `SMTSolverContext`object, which can access the specific context by calling `getContext()`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49233
llvm-svn: 337914
David Carlier [Wed, 25 Jul 2018 12:38:23 +0000 (12:38 +0000)]
[Asan][Msan] Unit tests Disable some tests for FreeBSD
Reviewers: krytarowski
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D49784
llvm-svn: 337913
Petar Jovanovic [Wed, 25 Jul 2018 12:35:01 +0000 (12:35 +0000)]
[MIPS GlobalISel] Lower pointer arguments
Add support for lowering pointer arguments.
Changing type from pointer to integer is already done in
MipsTargetLowering::getRegisterTypeForCallingConv.
Patch by Petar Avramovic.
Differential Revision: https://reviews.llvm.org/D49419
llvm-svn: 337912
Jonas Hahnfeld [Wed, 25 Jul 2018 12:34:31 +0000 (12:34 +0000)]
[OMPT] Fix typo in test parallel/nested_thread_num.c
This caused test failures with GCC since its initial commit in
r336085 (https://reviews.llvm.org/D46533).
llvm-svn: 337911
Pavel Labath [Wed, 25 Jul 2018 11:55:59 +0000 (11:55 +0000)]
dwarfgen: Add support for generating the debug_str_offsets section
Summary:
The motivation for this is D49493, where we'd like to test details of
debug_str_offsets behavior which is difficult to trigger from a
traditional test.
This adds the plubming necessary for dwarfgen to generate this section.
The more interesting changes are:
- I've moved emitStringOffsetsTableHeader function from DwarfFile to
DwarfStringPool, so I can generate the section header more easily from
the unit test.
- added a new addAttribute overload taking an MCExpr*. This is used to
generate the DW_AT_str_offsets_base, which links a compile unit to the
offset table.
I've also added a basic test for reading and writing DW_form_strx forms.
Reviewers: dblaikie, JDevlieghere, probinson
Subscribers: llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D49670
llvm-svn: 337910
Jonas Paulsson [Wed, 25 Jul 2018 11:42:55 +0000 (11:42 +0000)]
[SystemZ] Use tablegen loops in SchedModels
NFC changes to make scheduler TableGen files more readable, by using loops
instead of a lot of similar defs with just e.g. a latency value that changes.
https://reviews.llvm.org/D49598
Review: Ulrich Weigand, Javed Abshar
llvm-svn: 337909
Pavel Labath [Wed, 25 Jul 2018 11:35:28 +0000 (11:35 +0000)]
Fix PythonString::GetString for >=python-3.7
The return value of PyUnicode_AsUTF8AndSize is now "const char *".
Thanks to Brett Neumeier for testing the patch out on python 3.7.
llvm-svn: 337908
Eric Liu [Wed, 25 Jul 2018 11:26:35 +0000 (11:26 +0000)]
[clangd] Use a sigmoid style function for #usages boost in symbol quality.
Summary:
This has a shape to similar logarithm function but grows much slower for
large #usages.
Metrics: https://reviews.llvm.org/P8096
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, cfe-commits, sammccall
Differential Revision: https://reviews.llvm.org/D49780
llvm-svn: 337907
Eric Fiselier [Wed, 25 Jul 2018 11:19:13 +0000 (11:19 +0000)]
Fix dangling reference in test
llvm-svn: 337906
Eric Fiselier [Wed, 25 Jul 2018 11:16:39 +0000 (11:16 +0000)]
Fix diagnostic test to tolerate Clang diagnosing it as well.
Tuple has tests that ensure we diagnose non-lifetime extended
reference bindings inside tuples constructors. As of yesterday,
Clang now does this for us.
Adjust the test to tolerate the new diagnostics, while still
testing that we emit diagnostics of our own. Maybe after this
version of Clang has been adopted by most users we should
remove our diagnostics; but for now more error detection is
better!
llvm-svn: 337905
Florian Hahn [Wed, 25 Jul 2018 11:13:40 +0000 (11:13 +0000)]
Recommit r333268: [IPSCCP] Use PredicateInfo to propagate facts from cmp instructions.
r337828 resolves a PredicateInfo issue with unnamed types.
Original message:
This patch updates IPSCCP to use PredicateInfo to propagate
facts to true branches predicated by EQ and to false branches
predicated by NE.
As a follow up, we should be able to extend it to also propagate additional
facts about nonnull.
Reviewers: davide, mssimpso, dberlin, efriedma
Reviewed By: davide, dberlin
llvm-svn: 337904
Thomas Preud'homme [Wed, 25 Jul 2018 11:11:12 +0000 (11:11 +0000)]
Fix PR34170: Crash on inline asm with 64bit output in 32bit GPR
Add support for inline assembly with output operand that do not
naturally go in the register class it is constrained to (eg. double in a
32-bit GPR as in the PR).
llvm-svn: 337903
Paul Semel [Wed, 25 Jul 2018 11:09:20 +0000 (11:09 +0000)]
[llvm-objdump] Add dynamic section printing to private-headers option
Differential Revision: https://reviews.llvm.org/D49016
llvm-svn: 337902
Kirill Bobyrev [Wed, 25 Jul 2018 10:34:57 +0000 (10:34 +0000)]
[clangd] Introduce Dex symbol index search tokens
This patch introduces the core building block of the next-generation
Clangd symbol index - Dex. Search tokens are the keys in the inverted
index and represent a characteristic of a specific symbol: examples of
search token types (Token Namespaces) are
* Trigrams - these are essential for unqualified symbol name fuzzy
search * Scopes for filtering the symbols by the namespace * Paths, e.g.
these can be used to uprank symbols defined close to the edited file
This patch outlines the generic for such token namespaces, but only
implements trigram generation.
The intuition behind trigram generation algorithm is that each extracted
trigram is a valid sequence for Fuzzy Matcher jumps, proposed
implementation utilize existing FuzzyMatcher API for segmentation and
trigram extraction.
However, trigrams generation algorithm for the query string is different
from the previous one: it simply yields sequences of 3 consecutive
lowercased valid characters (letters, digits).
Dex RFC in the mailing list:
http://lists.llvm.org/pipermail/clangd-dev/2018-July/000022.html
The trigram generation techniques are described in detail in the
proposal:
https://docs.google.com/document/d/1C-A6PGT6TynyaX4PXyExNMiGmJ2jL1UwV91Kyx11gOI/edit#heading=h.903u1zon9nkj
Reviewers: sammccall, ioeric, ilya-biryukovA
Subscribers: cfe-commits, klimek, mgorny, MaskRay, jkorous, arphaman
Differential Revision: https://reviews.llvm.org/D49591
llvm-svn: 337901
Eric Fiselier [Wed, 25 Jul 2018 10:22:07 +0000 (10:22 +0000)]
Fix another typo in the FileTimeType docs
llvm-svn: 337900
Krasimir Georgiev [Wed, 25 Jul 2018 10:21:47 +0000 (10:21 +0000)]
[clang-format ]Extend IncludeCategories regex documentation
Summary:
Extend the Clang-Format IncludeCategories documentation by adding a link to the supported regular expression standard (POSIX).
And extenting the example with a system header regex.
[[ https://bugs.llvm.org/show_bug.cgi?id=35041 | bug 35041]]
Contributed by WimLeflere!
Reviewers: krasimir, Typz
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48827
llvm-svn: 337899
Balazs Keri [Wed, 25 Jul 2018 10:21:06 +0000 (10:21 +0000)]
[ASTImporter] Add support for import of CXXInheritedCtorInitExpr.
Reviewers: a.sidorin, martong
Reviewed By: martong
Subscribers: rnkovacs, a_sidorin, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D49293
llvm-svn: 337898
Eric Fiselier [Wed, 25 Jul 2018 10:17:04 +0000 (10:17 +0000)]
Fix typos, spelling, and grammar in the FileTimeType design docs.
I'm sure I'll discover more mistakes as I go on...
llvm-svn: 337897
Paul Semel [Wed, 25 Jul 2018 10:04:37 +0000 (10:04 +0000)]
[llvm-readobj] Generic hex-dump option
Helpers are available to make this option file format independant. This
patch adds the feature for Wasm file format. It doesn't change the
behavior of the other file format handling.
Differential Revision: https://reviews.llvm.org/D49545
llvm-svn: 337896
Chandler Carruth [Wed, 25 Jul 2018 09:18:48 +0000 (09:18 +0000)]
[x86/SLH] Sink the return hardening into the main block-walk + hardening
code.
This consolidates all our hardening calls, and simplifies the code
a bit. It seems much more clear to handle all of these together.
No functionality changed here.
llvm-svn: 337895
Chandler Carruth [Wed, 25 Jul 2018 09:00:26 +0000 (09:00 +0000)]
[x86/SLH] Improve name and comments for the main hardening function.
This function actually does two things: it traces the predicate state
through each of the basic blocks in the function (as that isn't directly
handled by the SSA updater) *and* it hardens everything necessary in the
block as it goes. These need to be done together so that we have the
currently active predicate state to use at each point of the hardening.
However, this also made obvious that the flag to disable actual
hardening of loads was flawed -- it also disabled tracing the predicate
state across function calls within the body of each block. So this patch
sinks this debugging flag test to correctly guard just the hardening of
loads.
Unless load hardening was disabled, no functionality should change with
tis patch.
llvm-svn: 337894
Simon Atanasyan [Wed, 25 Jul 2018 07:07:43 +0000 (07:07 +0000)]
[mips] Replace custom parsing logic for data directives by the `addAliasForDirective`
The target independent AsmParser doesn't recognise .hword, .word, .dword
which are required for Mips. Currently MipsAsmParser recognises these
through dispatch to MipsAsmParser::parseDataDirective. This contains
equivalent logic to AsmParser::parseDirectiveValue. This patch allows
reuse of AsmParser::parseDirectiveValue by making use of
addAliasForDirective to support .hword, .word and .dword.
Original patch provided by Alex Bradbury at D47001 was modified to fix
handling of microMIPS symbols. The `AsmParser::parseDirectiveValue`
calls either `EmitIntValue` or `EmitValue`. In this patch we override
`EmitIntValue` in the `MipsELFStreamer` to clear a pending set of
microMIPS symbols.
Differential revision: https://reviews.llvm.org/D49539
llvm-svn: 337893
Fangrui Song [Wed, 25 Jul 2018 06:57:31 +0000 (06:57 +0000)]
cc1_main: fix -Wsign-compare on FreeBSD
Its __rlim_t is intentionally signed (__int64_t) because of legacy code
that uses -1 for RLIM_INFINITY.
llvm-svn: 337892
Chijun Sima [Wed, 25 Jul 2018 06:18:33 +0000 (06:18 +0000)]
[Dominators] Assert if there is modification to DelBB while it is awaiting deletion
Summary:
Previously, passes use
```
DomTreeUpdater DTU(DT, DomTreeUpdater::UpdateStrategy::Lazy);
DTU.deleteBB(DelBB);
```
to delete a BasicBlock.
But passes which don't have the ability to update DomTree (e.g. tailcallelim, simplifyCFG) cannot recognize a DelBB awaiting deletion and will continue to process this DelBB.
This is a simple approach to notify devs of passes which may use DTU in the future to deal with deleted BasicBlocks under Lazy Strategy correctly.
Reviewers: kuhar, brzycki, dmgreen
Reviewed By: kuhar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49731
llvm-svn: 337891
Craig Topper [Wed, 25 Jul 2018 05:33:36 +0000 (05:33 +0000)]
[X86] Use X86ISD::MUL_IMM instead of ISD::MUL for multiply we intend to be selected to LEA.
This prevents other combines from possibly disturbing it.
llvm-svn: 337890
Craig Topper [Wed, 25 Jul 2018 05:22:13 +0000 (05:22 +0000)]
[X86] Autogenerate complete checks and fix a failure introduced in r337875.
llvm-svn: 337889
Eric Fiselier [Wed, 25 Jul 2018 04:46:32 +0000 (04:46 +0000)]
Fix bugs in create_directory implementation.
Libc++ was incorrectly reporting an error when the target of create_directory
already exists, but was not a directory. This behavior is not specified
in the most recent standard, which says no error should be reported.
Additionally, libc++ failed to report an error when the attribute directory
path didn't exist or didn't name a directory. This has been fixed as well.
Although it's not clear if we should call status or symlink_status on the
attribute directory. This patch chooses to still call status.
llvm-svn: 337888
JF Bastien [Wed, 25 Jul 2018 04:29:03 +0000 (04:29 +0000)]
CodeGen: use non-zero memset when possible for automatic variables
Summary:
Right now automatic variables are either initialized with bzero followed by a few stores, or memcpy'd from a synthesized global. We end up encountering a fair amount of code where memcpy of non-zero byte patterns would be better than memcpy from a global because it touches less memory and generates a smaller binary. The optimizer could reason about this, but it's not really worth it when clang already knows.
This code could definitely be more clever but I'm not sure it's worth it. In particular we could track a histogram of bytes seen and figure out (as we do with bzero) if a memset could be followed by a handful of stores. Similarly, we could tune the heuristics for GlobalSize, but using the same as for bzero seems conservatively OK for now.
<rdar://problem/
42563091>
Reviewers: dexonsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49771
llvm-svn: 337887
Eric Fiselier [Wed, 25 Jul 2018 04:21:59 +0000 (04:21 +0000)]
Fix missing includes in format_string.hpp helper
llvm-svn: 337886
Marshall Clow [Wed, 25 Jul 2018 04:21:21 +0000 (04:21 +0000)]
New test support for comparisons. Reviewed as https://reviews.llvm.org/D49773
llvm-svn: 337885
Eric Fiselier [Wed, 25 Jul 2018 03:41:31 +0000 (03:41 +0000)]
Make <experimental/filesystem> explicitly require C++11.
Previously the <experimental/filesystem> didn't guard its
contents in any dialect. However, the implementation implicitly
requires at least C++11, and the tests have always been marked
unsupported in C++03. This patch puts a header guard around the
contents to avoid exposing them before C++11.
Additionally, it replaces all of the usages of _NOEXCEPT or
_LIBCPP_CONSTEXPR with the keyword directly, since we can
expect the compiler to implement those by now.
llvm-svn: 337884
Eric Fiselier [Wed, 25 Jul 2018 03:31:48 +0000 (03:31 +0000)]
Ensure path::iterator and PathParser share the same enumeration values.
To avoid exposing implementation details, path::iterator and PathParser
both implicitly used the same set of values to represent the state,
but they were defined twice. This could have lead to a mismatch
occuring.
This patch moves all of the parser state values into the filesystem
header and changes PathParser to use those value to avoid this.
llvm-svn: 337883
Tom Stellard [Wed, 25 Jul 2018 03:08:35 +0000 (03:08 +0000)]
[RegisterBankInfo] Ignore InstrMappings that create impossible to repair operands
Summary:
This is a follow-up to r303043. In computeMapping(), we need to disqualify an
InstrMapping if it would be impossible to repair one of the registers in the
instruction to match the mapping.
This change is needed in order to be able to define an instruction
mapping for G_SELECT for the AMDGPU target and will be tested
by test/CodeGen/AMDGPU/GlobalISel/regbankselect-select.mir
Reviewers: ab, qcolombet, t.p.northover, dsanders
Reviewed By: qcolombet
Subscribers: tpr, llvm-commits
Differential Revision: https://reviews.llvm.org/D49735
llvm-svn: 337882
Petr Hosek [Wed, 25 Jul 2018 03:01:35 +0000 (03:01 +0000)]
[profile] Support profiling runtime on Fuchsia
This ports the profiling runtime on Fuchsia and enables the
instrumentation. Unlike on other platforms, Fuchsia doesn't use
files to dump the instrumentation data since on Fuchsia, filesystem
may not be accessible to the instrumented process. We instead use
the data sink to pass the profiling data to the system the same
sanitizer runtimes do.
Differential Revision: https://reviews.llvm.org/D47208
llvm-svn: 337881
Eric Fiselier [Wed, 25 Jul 2018 02:53:53 +0000 (02:53 +0000)]
Add design docs for upcoming file_time_type change.
In upcoming changes to filesystem I plan to change file_time_type
to use __int128_t as its underlying representation, in order
to allow it to have a range and resolution at least that of
the timespec struct.
There was some pushback against this decision, so I drafted
a document explaining the problems, potential solutions, and
the rational for the decision.
However, it's probably easier to let people read the generated
HTML rather than the raw restructured text. For this reason
I'm commiting the design documents before hand, so they can
be available during any subsequent discussion or code review.
llvm-svn: 337880
Marshall Clow [Wed, 25 Jul 2018 01:55:25 +0000 (01:55 +0000)]
Mark <span> as complete
llvm-svn: 337879
Chandler Carruth [Wed, 25 Jul 2018 01:51:29 +0000 (01:51 +0000)]
[x86/SLH] Teach the x86 speculative load hardening pass to harden
against v1.2 BCBS attacks directly.
Attacks using spectre v1.2 (a subset of BCBS) are described in the paper
here:
https://people.csail.mit.edu/vlk/spectre11.pdf
The core idea is to speculatively store over the address in a vtable,
jumptable, or other target of indirect control flow that will be
subsequently loaded. Speculative execution after such a store can
forward the stored value to subsequent loads, and if called or jumped
to, the speculative execution will be steered to this potentially
attacker controlled address.
Up until now, this could be mitigated by enableing retpolines. However,
that is a relatively expensive technique to mitigate this particular
flavor. Especially because in most cases SLH will have already mitigated
this. To fully mitigate this with SLH, we need to do two core things:
1) Unfold loads from calls and jumps, allowing the loads to be post-load
hardened.
2) Force hardening of incoming registers even if we didn't end up
needing to harden the load itself.
The reason we need to do these two things is because hardening calls and
jumps from this particular variant is importantly different from
hardening against leak of secret data. Because the "bad" data here isn't
a secret, but in fact speculatively stored by the attacker, it may be
loaded from any address, regardless of whether it is read-only memory,
mapped memory, or a "hardened" address. The only 100% effective way to
harden these instructions is to harden the their operand itself. But to
the extent possible, we'd like to take advantage of all the other
hardening going on, we just need a fallback in case none of that
happened to cover the particular input to the control transfer
instruction.
For users of SLH, currently they are paing 2% to 6% performance overhead
for retpolines, but this mechanism is expected to be substantially
cheaper. However, it is worth reminding folks that this does not
mitigate all of the things retpolines do -- most notably, variant #2 is
not in *any way* mitigated by this technique. So users of SLH may still
want to enable retpolines, and the implementation is carefuly designed to
gracefully leverage retpolines to avoid the need for further hardening
here when they are enabled.
Differential Revision: https://reviews.llvm.org/D49663
llvm-svn: 337878
Petr Hosek [Wed, 25 Jul 2018 01:44:22 +0000 (01:44 +0000)]
[CMake] Link static libunwind and libc++abi into libc++ in Fuchsia toolchain
When building libc++ for Fuchsia, we want to distribute shared libc++,
libc++abi and libunwind as separate libraries, but for static versions
we would like to link all of them into libc++ so -lc++ flag has the same
effect whether shared or static library is being used.
Differential Revision: https://reviews.llvm.org/D49628
llvm-svn: 337877
George Karpenkov [Wed, 25 Jul 2018 01:27:15 +0000 (01:27 +0000)]
[analyzer] Syntactic matcher for leaks associated with run loop and autoreleasepool
A checker for detecting leaks resulting from allocating temporary
autoreleasing objects before starting the main run loop.
Checks for two antipatterns:
1. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in the same
autorelease pool.
2. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in no
autorelease pool.
Happens-before relationship is modeled purely syntactically.
rdar://
39299145
Differential Revision: https://reviews.llvm.org/D49528
llvm-svn: 337876
Craig Topper [Wed, 25 Jul 2018 01:15:38 +0000 (01:15 +0000)]
[X86] Use a shift plus an lea for multiplying by a constant that is a power of 2 plus 2/4/8.
The LEA allows us to combine an add and the multiply by 2/4/8 together so we just need a shift for the larger power of 2.
llvm-svn: 337875
Craig Topper [Wed, 25 Jul 2018 01:15:35 +0000 (01:15 +0000)]
[X86] Expand mul by pow2 + 2 using a shift and two adds similar to what we do for pow2 - 2.
llvm-svn: 337874
Raphael Isemann [Tue, 24 Jul 2018 23:52:39 +0000 (23:52 +0000)]
Add unit tests for VMRange
Subscribers: clayborg, labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49415
llvm-svn: 337873
Matt Morehouse [Tue, 24 Jul 2018 23:50:42 +0000 (23:50 +0000)]
[sanitizer] Update symbolizer test.
llvm-svn: 337872
Craig Topper [Tue, 24 Jul 2018 23:44:17 +0000 (23:44 +0000)]
[X86] Use a two lea sequence for multiply by 37, 41, and 73.
These fit a pattern used by 11, 21, and 19.
llvm-svn: 337871
Craig Topper [Tue, 24 Jul 2018 23:44:15 +0000 (23:44 +0000)]
[X86] Add test cases for multiply by 37, 41, and 73.
These can all be handled with 2 LEAs similar to what we do for 11, 19, 21.
llvm-svn: 337870
Craig Topper [Tue, 24 Jul 2018 23:44:12 +0000 (23:44 +0000)]
[X86] Change multiply by 26 to use two multiplies by 5 and an add instead of multiply by 3 and 9 and a subtract.
Same number of operations, but ending in an add is friendlier due to it being commutable.
llvm-svn: 337869
Petr Hosek [Tue, 24 Jul 2018 23:42:51 +0000 (23:42 +0000)]
[CMake] Include CMakeDependentOption in libunwind
This should resolve the breakage introduced in r337867 which introduced
the use of cmake_dependent_option without include the necessary file.
llvm-svn: 337868
Petr Hosek [Tue, 24 Jul 2018 23:27:51 +0000 (23:27 +0000)]
[CMake] Option to control whether shared/static library is installed
Currently it's only possible to control whether shared or static library
build of libc++, libc++abi and libunwind is enabled or disabled and
whether to install everything we've built or not. However, it'd be
useful to have more fine grained control, e.g. when static libraries are
merged together into libc++.a we don't need to install libc++abi.a and
libunwind.a. This change adds this option.
Differential Revision: https://reviews.llvm.org/D49573
llvm-svn: 337867
George Karpenkov [Tue, 24 Jul 2018 23:23:33 +0000 (23:23 +0000)]
Revert "[analyzer] Extend NoStoreFuncVisitor to insert a note on IVars"
This reverts commit
a9e21bd727112cd69eabc1af648c5da6b773d06e.
Reverted because the dependency has not landed yet.
llvm-svn: 337866
Jason Molenda [Tue, 24 Jul 2018 23:19:56 +0000 (23:19 +0000)]
Add DumpRegisterValue.cpp.
llvm-svn: 337865
George Karpenkov [Tue, 24 Jul 2018 23:14:29 +0000 (23:14 +0000)]
[analyzer] Extend NoStoreFuncVisitor to insert a note on IVars
The note is added in the following situation:
- We are throwing a nullability-related warning on an IVar
- The path goes through a method which *could have* (syntactically
determined) written into that IVar, but did not
rdar://
42444460
Differential Revision: https://reviews.llvm.org/D49689
llvm-svn: 337864
Rui Ueyama [Tue, 24 Jul 2018 22:52:11 +0000 (22:52 +0000)]
Fix error messages for bad symbols.
Previously, the error messages didn't contain symbol name because we
didn't read a symbol name for these error messages.
Differential Revision: https://reviews.llvm.org/D49762
llvm-svn: 337863
Benjamin Kramer [Tue, 24 Jul 2018 22:47:16 +0000 (22:47 +0000)]
[Sema] Destroy tokens in DeclaratorChunk params
Otherwise this leaks in some edge cases.
llvm-svn: 337862
Hideki Saito [Tue, 24 Jul 2018 22:30:31 +0000 (22:30 +0000)]
[LV] Fix for PR38110, LV encountered llvm_unreachable()
Summary: truncateToMinimalBitWidths() doesn't handle all Instructions and the worst case is compiler crash via llvm_unreachable(). Fix is to add a case to handle PHINode and changed the worst case to NO-OP (from compiler crash).
Reviewers: sbaranga, mssimpso, hsaito
Reviewed By: hsaito
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49461
llvm-svn: 337861
Benjamin Kramer [Tue, 24 Jul 2018 21:50:06 +0000 (21:50 +0000)]
[clangd] Guard fuzzer against empty inputs.
llvm-svn: 337860
Roman Tereshin [Tue, 24 Jul 2018 21:48:56 +0000 (21:48 +0000)]
[SCEV] Add zext(C + x + ...) -> D + zext(C-D + x + ...)<nuw><nsw> transform
if the top level addition in (D + (C-D + x + ...)) could be proven to
not wrap, where the choice of D also maximizes the number of trailing
zeroes of (C-D + x + ...), ensuring homogeneous behaviour of the
transformation and better canonicalization of such expressions.
This enables better canonicalization of expressions like
1 + zext(5 + 20 * %x + 24 * %y) and
zext(6 + 20 * %x + 24 * %y)
which get both transformed to
2 + zext(4 + 20 * %x + 24 * %y)
This pattern is common in address arithmetics and the transformation
makes it easier for passes like LoadStoreVectorizer to prove that 2 or
more memory accesses are consecutive and optimize (vectorize) them.
Reviewed By: mzolotukhin
Differential Revision: https://reviews.llvm.org/D48853
llvm-svn: 337859
Craig Topper [Tue, 24 Jul 2018 21:31:21 +0000 (21:31 +0000)]
[X86] When expanding a multiply by a negative of one less than a power of 2, like 31, don't generate a negate of a subtract that we'll never optimize.
We generated a subtract for the power of 2 minus one then negated the result. The negate can be optimized away by swapping the subtract operands, but DAG combine doesn't know how to do that and we don't add any of the new nodes to the worklist anyway.
This patch makes use explicitly emit the swapped subtract.
llvm-svn: 337858
Richard Smith [Tue, 24 Jul 2018 21:18:30 +0000 (21:18 +0000)]
Don't lifetime-extend or track lifetime problems through the LHS of '->*'.
Fixes a false-positive warning found by selfhost.
llvm-svn: 337857
Craig Topper [Tue, 24 Jul 2018 21:15:41 +0000 (21:15 +0000)]
[X86] Generalize the multiply by 30 lowering to generic multipy by power 2 minus 2.
Use a left shift and 2 subtracts like we do for 30. Move this out from behind the slow lea check since it doesn't even use an LEA.
Use this for multiply by 14 as well.
llvm-svn: 337856
Raphael Isemann [Tue, 24 Jul 2018 21:09:17 +0000 (21:09 +0000)]
Remove unused History class
Summary: This class doesn't seem to be used anywhere, so we might as well remove the code.
Reviewers: labath
Reviewed By: labath
Subscribers: labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49755
llvm-svn: 337855
Heejin Ahn [Tue, 24 Jul 2018 21:06:44 +0000 (21:06 +0000)]
[WebAssembly] Add tests for weaker memory consistency orderings
Summary:
Currently all wasm atomic memory access instructions are sequentially
consistent, so even if LLVM IR specifies weaker orderings than that, we
should upgrade them to sequential ordering and treat them in the same
way.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D49194
llvm-svn: 337854
Max Moroz [Tue, 24 Jul 2018 21:02:44 +0000 (21:02 +0000)]
[libFuzzer] Handle unstable edges by disregarding unstable edges
Summary:
Added a new mode within flag -handle_unstable for new unstable handling algorithm that does the following:
When an edge is shown as unstable, copy to UnstableCounters the value 0.
During ApplyUnstableCounters we copy back the value 0 to ModuleInline8bitCounters if the edge was unstable.
This way we would be ignoring completely features that were collected through non-determinism.
Unstable hits would be counted as if it never hit.
Reviewers: metzman, Dor1s, kcc, morehouse
Reviewed By: metzman, morehouse
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49684
llvm-svn: 337853