| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isKnownNonNullFromDominatingCondition(); NFCI
I don't think this hole is currently exposed, but I crashed regression tests for
jump-threading and loop-vectorize after I added calls to isKnownNonNullAt() in
InstSimplify as part of trying to solve PR28430:
https://llvm.org/bugs/show_bug.cgi?id=28430
That's because they call into value tracking with a context instruction, but no
other parts of the query structure filled in.
For more background, see the discussion in:
https://reviews.llvm.org/D27855
llvm-svn: 290786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
These exception types are marked with `_LIBCPP_EXCEPTION_ABI` which
expands to `__attribute__((__visibility__("default")))` or
`__declspec(dllexport)`. When building for Windows, we would hit an
error:
cannot apply 'dllexport' to a 'dllexport' class
Remove the duplicate annotations as they will be inherited from the
class.
llvm-svn: 290785
|
| |
|
|
|
|
|
|
|
|
| |
This check detects and fixes redundant null checks before deletes.
Patch by: Gergely Angeli!
Differential Revision: https://reviews.llvm.org/D21298
llvm-svn: 290784
|
| |
|
|
|
|
| |
Even more isl coalesce changes.
llvm-svn: 290783
|
| |
|
|
| |
llvm-svn: 290782
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This diff fixes the clean build of the target generate-order-file.
In llvm/tools/clang/CMakeLists.txt
add_subdirectory(utils/perf-training) should go after the block where
the value of the variable CLANG_ORDER_FILE is set - otherwise
(tested with cmake's version 3.6.2) the arguments of perf-helper.py gen-order-file
will be ill-formed (CLANG_ORDER_FILE will be empty).
Differential revision: https://reviews.llvm.org/D28153
llvm-svn: 290781
|
| |
|
|
| |
llvm-svn: 290780
|
| |
|
|
|
|
|
|
| |
This was originally motivated by a compile time problem I've since figured out how to solve differently, but the cleanup seemed useful. We had the same logic - which essentially implemented find - in several places. By commoning them out, I can implement find and allow erase to be inlined at the call sites if profitable.
Differential Revision: https://reviews.llvm.org/D28183
llvm-svn: 290779
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR 31345
Reviewers: dylanmckay
Subscribers: fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D28186
llvm-svn: 290778
|
| |
|
|
| |
llvm-svn: 290777
|
| |
|
|
|
|
|
|
| |
llvm.x86.avx512.vcomi.ss don't use the upper elements of their input.
This was already done for the SSE/SSE2 version of the intrinsics.
llvm-svn: 290776
|
| |
|
|
|
|
|
| |
We need to include __config to ensure that we know what random
implementation is being used. Fixes compilation for Windows.
llvm-svn: 290775
|
| |
|
|
|
|
|
|
| |
don't emit a select if the mask is known to be all ones.
This saves InstCombine the burden of having to optimize the select later.
llvm-svn: 290774
|
| |
|
|
| |
llvm-svn: 290773
|
| |
|
|
| |
llvm-svn: 290772
|
| |
|
|
|
|
| |
Inconsistent naming convention and wrong name for some input/output types.
llvm-svn: 290771
|
| |
|
|
| |
llvm-svn: 290770
|
| |
|
|
| |
llvm-svn: 290769
|
| |
|
|
|
|
| |
Minor compile time win. Avoids an additional O(N) scan in the case where we are removing an element and costs nothing when we aren't.
llvm-svn: 290768
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Update the Phabricator docs to clarify how changes are merged for contributors without commit access.
Reviewers: delcypher, aaron.ballman
Subscribers: aaron.ballman, anmol, llvm-commits
Differential Revision: https://reviews.llvm.org/D28184
llvm-svn: 290767
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a small error in the code in the tutorial. The tutorial contains a few errors which results in code not being able to compile.
One error was described here: https://llvm.org/bugs/show_bug.cgi?id=25583 .
I found and fixed the error and one additional error.
Reviewers: aaron.ballman, malcolm.parsons
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28180
llvm-svn: 290766
|
| |
|
|
|
|
|
| |
Since we type-erase the Windows GUID structure, use unsigned bytes
rather than char, which may be signed (-fsigned-char). NFC
llvm-svn: 290765
|
| |
|
|
|
|
|
|
|
| |
Assert that the size of the MD5 result is the same size as the signature
field being populated. Use the sizeof operator to determine the size of
the field being written rather than hardcoding it to the magic number
16. NFC.
llvm-svn: 290764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
gep 0, 0 is equivalent to bitcast. LLVM canonicalizes it
to getelementptr because it make SROA can then handle it.
Simple case like
void g(A &a) {
z(a);
if (glob)
a.foo();
}
void testG() {
A a;
g(a);
}
was not devirtualized with -fstrict-vtable-pointers because luck of
handling for gep 0 in Memory Dependence Analysis
Reviewers: dberlin, nlewycky, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28126
llvm-svn: 290763
|
| |
|
|
|
|
|
| |
Change the cascading ifs to a StringSwitch to simplify the conversion of
the relocation model. NFC
llvm-svn: 290762
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
string::find used to call the generic algorithm ::find. The patch special
case string::find such that it ultimately gets converted to calls to memchr
and memcmp.
The patch improves the performance of the string::find routine by about 20x.
Without the patch, the performance on an x86_64-linux 3400 MHz machine is:
Benchmark Time CPU Iterations
-----------------------------------------------------------------
BM_StringFindNoMatch/10 4 ns 4 ns 166421326
BM_StringFindNoMatch/64 37 ns 37 ns 18754392
BM_StringFindNoMatch/512 268 ns 268 ns 2586060
BM_StringFindNoMatch/4k 2143 ns 2144 ns 328342
BM_StringFindNoMatch/32k 16910 ns 16917 ns 40623
BM_StringFindNoMatch/128k 67577 ns 67602 ns 10138
BM_StringFindAllMatch/1 3 ns 3 ns 265163471
BM_StringFindAllMatch/8 6 ns 6 ns 112582467
BM_StringFindAllMatch/64 36 ns 36 ns 19566457
BM_StringFindAllMatch/512 209 ns 209 ns 3318893
BM_StringFindAllMatch/4k 1618 ns 1618 ns 432963
BM_StringFindAllMatch/32k 12909 ns 12914 ns 54317
BM_StringFindAllMatch/128k 48342 ns 48361 ns 13922
BM_StringFindMatch1/1 33777 ns 33790 ns 20698
BM_StringFindMatch1/8 33940 ns 33953 ns 20619
BM_StringFindMatch1/64 34038 ns 34051 ns 20571
BM_StringFindMatch1/512 34217 ns 34230 ns 20480
BM_StringFindMatch1/4k 35510 ns 35524 ns 19752
BM_StringFindMatch1/32k 46438 ns 46456 ns 15030
BM_StringFindMatch2/1 33839 ns 33852 ns 20648
BM_StringFindMatch2/8 33950 ns 33963 ns 20594
BM_StringFindMatch2/64 33846 ns 33859 ns 20668
BM_StringFindMatch2/512 34023 ns 34036 ns 20279
BM_StringFindMatch2/4k 35422 ns 35436 ns 19716
BM_StringFindMatch2/32k 46570 ns 46588 ns 15027
With the patch applied
Benchmark Time CPU Iterations
-----------------------------------------------------------------
BM_StringFindNoMatch/10 5 ns 5 ns 133724346
BM_StringFindNoMatch/64 6 ns 6 ns 119312184
BM_StringFindNoMatch/512 13 ns 13 ns 51539628
BM_StringFindNoMatch/4k 77 ns 77 ns 8935934
BM_StringFindNoMatch/32k 551 ns 551 ns 1222808
BM_StringFindNoMatch/128k 2684 ns 2685 ns 259957
BM_StringFindAllMatch/1 7 ns 7 ns 98017959
BM_StringFindAllMatch/8 7 ns 7 ns 91466911
BM_StringFindAllMatch/64 8 ns 8 ns 85707392
BM_StringFindAllMatch/512 20 ns 20 ns 34490895
BM_StringFindAllMatch/4k 93 ns 93 ns 7360375
BM_StringFindAllMatch/32k 827 ns 828 ns 829944
BM_StringFindAllMatch/128k 3593 ns 3594 ns 195815
BM_StringFindMatch1/1 1332 ns 1332 ns 516354
BM_StringFindMatch1/8 1336 ns 1336 ns 495876
BM_StringFindMatch1/64 1338 ns 1339 ns 516656
BM_StringFindMatch1/512 1357 ns 1357 ns 510717
BM_StringFindMatch1/4k 1485 ns 1486 ns 461228
BM_StringFindMatch1/32k 2235 ns 2236 ns 318253
BM_StringFindMatch2/1 1335 ns 1335 ns 517105
BM_StringFindMatch2/8 1336 ns 1337 ns 518004
BM_StringFindMatch2/64 1344 ns 1345 ns 511751
BM_StringFindMatch2/512 1361 ns 1361 ns 508150
BM_StringFindMatch2/4k 1611 ns 1611 ns 463388
BM_StringFindMatch2/32k 2187 ns 2187 ns 317532
Patch written by Aditya Kumar and Sebastian Pop.
Differential Revision: https://reviews.llvm.org/D27068
llvm-svn: 290761
|
| |
|
|
|
|
|
|
| |
CVP doesn't care about the order of blocks visited, but by using a pre-order traversal over the graph we can a) not visit unreachable blocks and b) optimize as we go so that analysis of later blocks produce slightly more precise results.
I noticed this via inspection and don't have a concrete example which points to the issue.
llvm-svn: 290760
|
| |
|
|
|
|
| |
Minor compile time win. Not known to be a hot spot, just something I noticed while reading.
llvm-svn: 290759
|
| |
|
|
| |
llvm-svn: 290758
|
| |
|
|
|
|
| |
an unlikely thing to regress in the future.
llvm-svn: 290757
|
| |
|
|
| |
llvm-svn: 290756
|
| |
|
|
| |
llvm-svn: 290755
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two problems with the initial fix.
1. The added tests flushed out that we misconfigured _LIBCPP_EXPLICIT with GCC.
2. Because the boolean type was a member function template it caused weird link
errors. I'm assuming due to the vague linkage rules. This time the bool type
is a non-template member function pointer. That seems to have fixed the
failing tests. Plus it will end up generating less symbols overall, since
the bool type is no longer per instantiation.
original commit message below
-----------------------------
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
llvm-svn: 290754
|
| |
|
|
| |
llvm-svn: 290753
|
| |
|
|
| |
llvm-svn: 290752
|
| |
|
|
| |
llvm-svn: 290751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
llvm-svn: 290750
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
function) of SmallPtrSetIterator is used.
The bug was introduced in r289619.
Reviewers: Mehdi Amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28134
llvm-svn: 290749
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back in r240527 I added a knob to prevent thread-unsafe functions from
being exposed. mblen(), mbtowc() and wctomb() were also added to this
list, as the latest issue of POSIX doesn't require these functions to be
thread-safe.
It turns out that the only circumstance in which these functions are not
thread-safe is in case they are used in combination with state-dependent
character sets (e.g., Shift-JIS). According to Austin Group Bug 708,
these character sets "[...] are mostly a relic of the past and which
were never supported on most POSIX systems".
Though in many cases the use of these functions can be prevented by
using the reentrant counterparts, they are the only functions that allow
you to query whether the locale's character set is state-dependent. This
means that omitting these functions removes actual functionality.
Let's be a bit less pedantic and drop the guards around these functions.
Links:
http://austingroupbugs.net/view.php?id=708
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2037.htm
Reviewed by: ericwf
Differential Revision: https://reviews.llvm.org/D21436
llvm-svn: 290748
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have a created a new check for clang tidy: misc-string-compare. This will check for incorrect usage of std::string::compare when used to check equality or inequality of string instead of the string equality or inequality operators.
Example:
```
std::string str1, str2;
if (str1.compare(str2)) {
}
```
Reviewers: hokein, aaron.ballman, alexfh, malcolm.parsons
Subscribers: xazax.hun, Eugene.Zelenko, cfe-commits, malcolm.parsons, Prazek, mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D27210
llvm-svn: 290747
|
| |
|
|
| |
llvm-svn: 290746
|
| |
|
|
| |
llvm-svn: 290745
|
| |
|
|
|
|
|
| |
This implements the compiler side of p0403r0. This patch was reviewed as
https://reviews.llvm.org/D26829.
llvm-svn: 290744
|
| |
|
|
| |
llvm-svn: 290743
|
| |
|
|
| |
llvm-svn: 290742
|
| |
|
|
| |
llvm-svn: 290741
|
| |
|
|
|
|
|
|
| |
I remove one extra line, but because annoyingly llvm-lit does not
clean the output directory before running the test, it didn't fail
locally (the file was present from a previous run).
llvm-svn: 290740
|
| |
|
|
| |
llvm-svn: 290739
|
| |
|
|
|
|
|
|
|
| |
This is similar to the allocfn case - if an alloca is not captured, then it's
necessarily thread-local.
Differential Revision: https://reviews.llvm.org/D28170
llvm-svn: 290738
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current loop complete unroll algorithm checks if unrolling complete will reduce the runtime by a certain percentage. If yes, it will apply a fixed boosting factor to the threshold (by discounting cost). The problem for this approach is that the threshold abruptly. This patch makes the boosting factor a function of runtime reduction percentage, capped by a fixed threshold. In this way, the threshold changes continuously.
The patch also simplified the code by reducing one parameter in UP.
The patch only affects code-gen of two speccpu2006 benchmark:
445.gobmk binary size decreases 0.08%, no performance change.
464.h264ref binary size increases 0.24%, no performance change.
Reviewers: mzolotukhin, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26989
llvm-svn: 290737
|