summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [yaml2obj][obj2yaml] - Use a single "Other" field instead of "Other", ↵George Rimar2019-08-3012-187/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Visibility" and "StOther". Currenly we can encode the 'st_other' field of symbol using 3 fields. 'Visibility' is used to encode STV_* values. 'Other' is used to encode everything except the visibility, but it can't handle arbitrary values. 'StOther' is used to encode arbitrary values when 'Visibility'/'Other' are not helpfull enough. 'st_other' field is used to encode symbol visibility and platform-dependent flags and values. Problem to encode it is that it consists of Visibility part (STV_* values) which are enumeration values and the Other part, which is different and inconsistent. For MIPS the Other part contains flags for all STO_MIPS_* values except STO_MIPS_MIPS16. (Like comment in ELFDumper says: "Someones in their infinite wisdom decided to make STO_MIPS_MIPS16 flag overlapped with other ST_MIPS_xxx flags."...) And for PPC64 the Other part might actually encode any value. This patch implements custom logic for handling the st_other and removes 'Visibility' and 'StOther' fields. Here is an example of a new YAML style this patch allows: - Name: foo Other: [ 0x4 ] - Name: bar Other: [ STV_PROTECTED, 4 ] - Name: zed Other: [ STV_PROTECTED, STO_MIPS_OPTIONAL, 0xf8 ] Differential revision: https://reviews.llvm.org/D66886 llvm-svn: 370472
* [DAGCombine] visitVSELECT - use getShiftAmountTy for shift amounts.Simon Pilgrim2019-08-301-3/+3
| | | | llvm-svn: 370471
* [DAGCombine] visitMULHS - use getScalarValueSizeInBits() to make safe for ↵Simon Pilgrim2019-08-301-1/+1
| | | | | | | | vector types. This is hidden behind a (scalar-only) isOneConstant(N1) check at the moment, but once we get around to adding vector support we need to ensure we're dealing with the scalar bitwidth, not the total. llvm-svn: 370468
* [mips] Merge common checkings under the same check prefix. NFCSimon Atanasyan2019-08-301-48/+34
| | | | llvm-svn: 370467
* [RISCV] Fix a couple of tests' CHECKsLuis Marques2019-08-302-84/+659
| | | | llvm-svn: 370466
* Remove an extra ";", NFC.Haojian Wu2019-08-301-1/+1
| | | | llvm-svn: 370465
* [X86] Add tests for rotate matching. NFCAmaury Sechet2019-08-302-0/+70
| | | | llvm-svn: 370464
* [CodeGen] Introduce MachineBasicBlock::replacePhiUsesWith helper and use it. NFCBjorn Pettersson2019-08-303-24/+20
| | | | | | | | | | | | | | | | | | | | | Summary: Found a couple of places in the code where all the PHI nodes of a MBB is updated, replacing references to one MBB by reference to another MBB instead. This patch simply refactors the code to use a common helper (MachineBasicBlock::replacePhiUsesWith) for such PHI node updates. Reviewers: t.p.northover, arsenm, uabelho Subscribers: wdng, hiraditya, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66750 llvm-svn: 370463
* [dotest] Finish removing -qPavel Labath2019-08-301-1/+1
| | | | | | | One usage of this option remained, and caused dotest to error out if one happened to pass the -v flag. llvm-svn: 370462
* [ASTImporter] Do not look up lambda classesGabor Marton2019-08-302-1/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Consider this code: ``` void f() { auto L0 = [](){}; auto L1 = [](){}; } ``` First we import `L0` then `L1`. Currently we end up having only one CXXRecordDecl for the two different lambdas. And that is a problem if the body of their op() is different. This happens because when we import `L1` then lookup finds the existing `L0` and since they are structurally equivalent we just map the imported L0 to be the counterpart of L1. We have the same problem in this case: ``` template <typename F0, typename F1> void f(F0 L0 = [](){}, F1 L1 = [](){}) {} ``` In StructuralEquivalenceContext we could distinquish lambdas only by their source location in these cases. But we the lambdas are actually structrually equivalent they differn only by the source location. Thus, the solution is to disable lookup completely if the decl in the "from" context is a lambda. However, that could have other problems: what if the lambda is defined in a header file and included in several TUs? I think we'd have as many duplicates as many includes we have. I think we could live with that, because the lambda classes are TU local anyway, we cannot just access them from another TU. Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66348 llvm-svn: 370461
* [DAGCombine] visitMULHS/visitMULHU - isBuildVectorAllZeros doesn't mean node ↵Simon Pilgrim2019-08-301-8/+8
| | | | | | | | | | is all zeros Return a proper zero vector, just in case some elements are undef. Noticed by inspection after dealing with a similar issue in PR43159. llvm-svn: 370460
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2019-08-301-2/+2
| | | | llvm-svn: 370459
* [llvm-objcopy] Allow the visibility of symbols created by --binary andChris Jackson2019-08-3011-23/+111
| | | | | | --add-symbol to be specified with --new-symbol-visibility llvm-svn: 370458
* [ASTImporter] Propagate errors during import of overridden methods.Balazs Keri2019-08-302-5/+55
| | | | | | | | | | | | | | | | | | | Summary: If importing overridden methods fails for a method it can be seen incorrectly as non-virtual. To avoid this inconsistency the method is marked with import error to avoid later use of it. Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: martong, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66933 llvm-svn: 370457
* [Attributor] Implement AANoAliasCallSiteArgument initializationHideto Ueno2019-08-302-7/+14
| | | | | | | | | | | | | | | | Summary: This patch adds an appropriate `initialize` method for `AANoAliasCallSiteArgument`. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66927 llvm-svn: 370456
* [Clangd] ExtractFunction Added checks for broken control flowShaurya Gupta2019-08-302-17/+75
| | | | | | | | | | | | | | | | Summary: - Added checks for broken control flow - Added unittests Reviewers: sammccall, kadircet Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66732 llvm-svn: 370455
* [LoopIdiomRecognize] BCmp loop idiom recognitionRoman Lebedev2019-08-306-588/+1271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: @mclow.lists brought up this issue up in IRC. It is a reasonably common problem to compare some two values for equality. Those may be just some integers, strings or arrays of integers. In C, there is `memcmp()`, `bcmp()` functions. In C++, there exists `std::equal()` algorithm. One can also write that function manually. libstdc++'s `std::equal()` is specialized to directly call `memcmp()` for various types, but not `std::byte` from C++2a. https://godbolt.org/z/mx2ejJ libc++ does not do anything like that, it simply relies on simple C++'s `operator==()`. https://godbolt.org/z/er0Zwf (GOOD!) So likely, there exists a certain performance opportunities. Let's compare performance of naive `std::equal()` (no `memcmp()`) with one that is using `memcmp()` (in this case, compiled with modified compiler). {F8768213} ``` #include <algorithm> #include <cmath> #include <cstdint> #include <iterator> #include <limits> #include <random> #include <type_traits> #include <utility> #include <vector> #include "benchmark/benchmark.h" template <class T> bool equal(T* a, T* a_end, T* b) noexcept { for (; a != a_end; ++a, ++b) { if (*a != *b) return false; } return true; } template <typename T> std::vector<T> getVectorOfRandomNumbers(size_t count) { std::random_device rd; std::mt19937 gen(rd()); std::uniform_int_distribution<T> dis(std::numeric_limits<T>::min(), std::numeric_limits<T>::max()); std::vector<T> v; v.reserve(count); std::generate_n(std::back_inserter(v), count, [&dis, &gen]() { return dis(gen); }); assert(v.size() == count); return v; } struct Identical { template <typename T> static std::pair<std::vector<T>, std::vector<T>> Gen(size_t count) { auto Tmp = getVectorOfRandomNumbers<T>(count); return std::make_pair(Tmp, std::move(Tmp)); } }; struct InequalHalfway { template <typename T> static std::pair<std::vector<T>, std::vector<T>> Gen(size_t count) { auto V0 = getVectorOfRandomNumbers<T>(count); auto V1 = V0; V1[V1.size() / size_t(2)]++; // just change the value. return std::make_pair(std::move(V0), std::move(V1)); } }; template <class T, class Gen> void BM_bcmp(benchmark::State& state) { const size_t Length = state.range(0); const std::pair<std::vector<T>, std::vector<T>> Data = Gen::template Gen<T>(Length); const std::vector<T>& a = Data.first; const std::vector<T>& b = Data.second; assert(a.size() == Length && b.size() == a.size()); benchmark::ClobberMemory(); benchmark::DoNotOptimize(a); benchmark::DoNotOptimize(a.data()); benchmark::DoNotOptimize(b); benchmark::DoNotOptimize(b.data()); for (auto _ : state) { const bool is_equal = equal(a.data(), a.data() + a.size(), b.data()); benchmark::DoNotOptimize(is_equal); } state.SetComplexityN(Length); state.counters["eltcnt"] = benchmark::Counter(Length, benchmark::Counter::kIsIterationInvariant); state.counters["eltcnt/sec"] = benchmark::Counter(Length, benchmark::Counter::kIsIterationInvariantRate); const size_t BytesRead = 2 * sizeof(T) * Length; state.counters["bytes_read/iteration"] = benchmark::Counter(BytesRead, benchmark::Counter::kDefaults, benchmark::Counter::OneK::kIs1024); state.counters["bytes_read/sec"] = benchmark::Counter( BytesRead, benchmark::Counter::kIsIterationInvariantRate, benchmark::Counter::OneK::kIs1024); } template <typename T> static void CustomArguments(benchmark::internal::Benchmark* b) { const size_t L2SizeBytes = []() { for (const benchmark::CPUInfo::CacheInfo& I : benchmark::CPUInfo::Get().caches) { if (I.level == 2) return I.size; } return 0; }(); // What is the largest range we can check to always fit within given L2 cache? const size_t MaxLen = L2SizeBytes / /*total bufs*/ 2 / /*maximal elt size*/ sizeof(T) / /*safety margin*/ 2; b->RangeMultiplier(2)->Range(1, MaxLen)->Complexity(benchmark::oN); } BENCHMARK_TEMPLATE(BM_bcmp, uint8_t, Identical) ->Apply(CustomArguments<uint8_t>); BENCHMARK_TEMPLATE(BM_bcmp, uint16_t, Identical) ->Apply(CustomArguments<uint16_t>); BENCHMARK_TEMPLATE(BM_bcmp, uint32_t, Identical) ->Apply(CustomArguments<uint32_t>); BENCHMARK_TEMPLATE(BM_bcmp, uint64_t, Identical) ->Apply(CustomArguments<uint64_t>); BENCHMARK_TEMPLATE(BM_bcmp, uint8_t, InequalHalfway) ->Apply(CustomArguments<uint8_t>); BENCHMARK_TEMPLATE(BM_bcmp, uint16_t, InequalHalfway) ->Apply(CustomArguments<uint16_t>); BENCHMARK_TEMPLATE(BM_bcmp, uint32_t, InequalHalfway) ->Apply(CustomArguments<uint32_t>); BENCHMARK_TEMPLATE(BM_bcmp, uint64_t, InequalHalfway) ->Apply(CustomArguments<uint64_t>); ``` {F8768210} ``` $ ~/src/googlebenchmark/tools/compare.py --no-utest benchmarks build-{old,new}/test/llvm-bcmp-bench RUNNING: build-old/test/llvm-bcmp-bench --benchmark_out=/tmp/tmpb6PEUx 2019-04-25 21:17:11 Running build-old/test/llvm-bcmp-bench Run on (8 X 4000 MHz CPU s) CPU Caches: L1 Data 16K (x8) L1 Instruction 64K (x4) L2 Unified 2048K (x4) L3 Unified 8192K (x1) Load Average: 0.65, 3.90, 4.14 --------------------------------------------------------------------------------------------------- Benchmark Time CPU Iterations UserCounters... --------------------------------------------------------------------------------------------------- <...> BM_bcmp<uint8_t, Identical>/512000 432131 ns 432101 ns 1613 bytes_read/iteration=1000k bytes_read/sec=2.20706G/s eltcnt=825.856M eltcnt/sec=1.18491G/s BM_bcmp<uint8_t, Identical>_BigO 0.86 N 0.86 N BM_bcmp<uint8_t, Identical>_RMS 8 % 8 % <...> BM_bcmp<uint16_t, Identical>/256000 161408 ns 161409 ns 4027 bytes_read/iteration=1000k bytes_read/sec=5.90843G/s eltcnt=1030.91M eltcnt/sec=1.58603G/s BM_bcmp<uint16_t, Identical>_BigO 0.67 N 0.67 N BM_bcmp<uint16_t, Identical>_RMS 25 % 25 % <...> BM_bcmp<uint32_t, Identical>/128000 81497 ns 81488 ns 8415 bytes_read/iteration=1000k bytes_read/sec=11.7032G/s eltcnt=1077.12M eltcnt/sec=1.57078G/s BM_bcmp<uint32_t, Identical>_BigO 0.71 N 0.71 N BM_bcmp<uint32_t, Identical>_RMS 42 % 42 % <...> BM_bcmp<uint64_t, Identical>/64000 50138 ns 50138 ns 10909 bytes_read/iteration=1000k bytes_read/sec=19.0209G/s eltcnt=698.176M eltcnt/sec=1.27647G/s BM_bcmp<uint64_t, Identical>_BigO 0.84 N 0.84 N BM_bcmp<uint64_t, Identical>_RMS 27 % 27 % <...> BM_bcmp<uint8_t, InequalHalfway>/512000 192405 ns 192392 ns 3638 bytes_read/iteration=1000k bytes_read/sec=4.95694G/s eltcnt=1.86266G eltcnt/sec=2.66124G/s BM_bcmp<uint8_t, InequalHalfway>_BigO 0.38 N 0.38 N BM_bcmp<uint8_t, InequalHalfway>_RMS 3 % 3 % <...> BM_bcmp<uint16_t, InequalHalfway>/256000 127858 ns 127860 ns 5477 bytes_read/iteration=1000k bytes_read/sec=7.45873G/s eltcnt=1.40211G eltcnt/sec=2.00219G/s BM_bcmp<uint16_t, InequalHalfway>_BigO 0.50 N 0.50 N BM_bcmp<uint16_t, InequalHalfway>_RMS 0 % 0 % <...> BM_bcmp<uint32_t, InequalHalfway>/128000 49140 ns 49140 ns 14281 bytes_read/iteration=1000k bytes_read/sec=19.4072G/s eltcnt=1.82797G eltcnt/sec=2.60478G/s BM_bcmp<uint32_t, InequalHalfway>_BigO 0.40 N 0.40 N BM_bcmp<uint32_t, InequalHalfway>_RMS 18 % 18 % <...> BM_bcmp<uint64_t, InequalHalfway>/64000 32101 ns 32099 ns 21786 bytes_read/iteration=1000k bytes_read/sec=29.7101G/s eltcnt=1.3943G eltcnt/sec=1.99381G/s BM_bcmp<uint64_t, InequalHalfway>_BigO 0.50 N 0.50 N BM_bcmp<uint64_t, InequalHalfway>_RMS 1 % 1 % RUNNING: build-new/test/llvm-bcmp-bench --benchmark_out=/tmp/tmpQ46PP0 2019-04-25 21:19:29 Running build-new/test/llvm-bcmp-bench Run on (8 X 4000 MHz CPU s) CPU Caches: L1 Data 16K (x8) L1 Instruction 64K (x4) L2 Unified 2048K (x4) L3 Unified 8192K (x1) Load Average: 1.01, 2.85, 3.71 --------------------------------------------------------------------------------------------------- Benchmark Time CPU Iterations UserCounters... --------------------------------------------------------------------------------------------------- <...> BM_bcmp<uint8_t, Identical>/512000 18593 ns 18590 ns 37565 bytes_read/iteration=1000k bytes_read/sec=51.2991G/s eltcnt=19.2333G eltcnt/sec=27.541G/s BM_bcmp<uint8_t, Identical>_BigO 0.04 N 0.04 N BM_bcmp<uint8_t, Identical>_RMS 37 % 37 % <...> BM_bcmp<uint16_t, Identical>/256000 18950 ns 18948 ns 37223 bytes_read/iteration=1000k bytes_read/sec=50.3324G/s eltcnt=9.52909G eltcnt/sec=13.511G/s BM_bcmp<uint16_t, Identical>_BigO 0.08 N 0.08 N BM_bcmp<uint16_t, Identical>_RMS 34 % 34 % <...> BM_bcmp<uint32_t, Identical>/128000 18627 ns 18627 ns 37895 bytes_read/iteration=1000k bytes_read/sec=51.198G/s eltcnt=4.85056G eltcnt/sec=6.87168G/s BM_bcmp<uint32_t, Identical>_BigO 0.16 N 0.16 N BM_bcmp<uint32_t, Identical>_RMS 35 % 35 % <...> BM_bcmp<uint64_t, Identical>/64000 18855 ns 18855 ns 37458 bytes_read/iteration=1000k bytes_read/sec=50.5791G/s eltcnt=2.39731G eltcnt/sec=3.3943G/s BM_bcmp<uint64_t, Identical>_BigO 0.32 N 0.32 N BM_bcmp<uint64_t, Identical>_RMS 33 % 33 % <...> BM_bcmp<uint8_t, InequalHalfway>/512000 9570 ns 9569 ns 73500 bytes_read/iteration=1000k bytes_read/sec=99.6601G/s eltcnt=37.632G eltcnt/sec=53.5046G/s BM_bcmp<uint8_t, InequalHalfway>_BigO 0.02 N 0.02 N BM_bcmp<uint8_t, InequalHalfway>_RMS 29 % 29 % <...> BM_bcmp<uint16_t, InequalHalfway>/256000 9547 ns 9547 ns 74343 bytes_read/iteration=1000k bytes_read/sec=99.8971G/s eltcnt=19.0318G eltcnt/sec=26.8159G/s BM_bcmp<uint16_t, InequalHalfway>_BigO 0.04 N 0.04 N BM_bcmp<uint16_t, InequalHalfway>_RMS 29 % 29 % <...> BM_bcmp<uint32_t, InequalHalfway>/128000 9396 ns 9394 ns 73521 bytes_read/iteration=1000k bytes_read/sec=101.518G/s eltcnt=9.41069G eltcnt/sec=13.6255G/s BM_bcmp<uint32_t, InequalHalfway>_BigO 0.08 N 0.08 N BM_bcmp<uint32_t, InequalHalfway>_RMS 30 % 30 % <...> BM_bcmp<uint64_t, InequalHalfway>/64000 9499 ns 9498 ns 73802 bytes_read/iteration=1000k bytes_read/sec=100.405G/s eltcnt=4.72333G eltcnt/sec=6.73808G/s BM_bcmp<uint64_t, InequalHalfway>_BigO 0.16 N 0.16 N BM_bcmp<uint64_t, InequalHalfway>_RMS 28 % 28 % Comparing build-old/test/llvm-bcmp-bench to build-new/test/llvm-bcmp-bench Benchmark Time CPU Time Old Time New CPU Old CPU New --------------------------------------------------------------------------------------------------------------------------------------- <...> BM_bcmp<uint8_t, Identical>/512000 -0.9570 -0.9570 432131 18593 432101 18590 <...> BM_bcmp<uint16_t, Identical>/256000 -0.8826 -0.8826 161408 18950 161409 18948 <...> BM_bcmp<uint32_t, Identical>/128000 -0.7714 -0.7714 81497 18627 81488 18627 <...> BM_bcmp<uint64_t, Identical>/64000 -0.6239 -0.6239 50138 18855 50138 18855 <...> BM_bcmp<uint8_t, InequalHalfway>/512000 -0.9503 -0.9503 192405 9570 192392 9569 <...> BM_bcmp<uint16_t, InequalHalfway>/256000 -0.9253 -0.9253 127858 9547 127860 9547 <...> BM_bcmp<uint32_t, InequalHalfway>/128000 -0.8088 -0.8088 49140 9396 49140 9394 <...> BM_bcmp<uint64_t, InequalHalfway>/64000 -0.7041 -0.7041 32101 9499 32099 9498 ``` What can we tell from the benchmark? * Performance of naive equality check somewhat improves with element size, maxing out at eltcnt/sec=1.58603G/s for uint16_t, or bytes_read/sec=19.0209G/s for uint64_t. I think, that instability implies performance problems. * Performance of `memcmp()`-aware benchmark always maxes out at around bytes_read/sec=51.2991G/s for every type. That is 2.6x the throughput of the naive variant! * eltcnt/sec metric for the `memcmp()`-aware benchmark maxes out at eltcnt/sec=27.541G/s for uint8_t (was: eltcnt/sec=1.18491G/s, so 24x) and linearly decreases with element size. For uint64_t, it's ~4x+ the elements/second. * The call obvious is more pricey than the loop, with small element count. As it can be seen from the full output {F8768210}, the `memcmp()` is almost universally worse, independent of the element size (and thus buffer size) when element count is less than 8. So all in all, bcmp idiom does indeed pose untapped performance headroom. This diff does implement said idiom recognition. I think a reasonable test coverage is present, but do tell if there is anything obvious missing. Now, quality. This does succeed to build and pass the test-suite, at least without any non-bundled elements. {F8768216} {F8768217} This transform fires 91 times: ``` $ /build/test-suite/utils/compare.py -m loop-idiom.NumBCmp result-new.json Tests: 1149 Metric: loop-idiom.NumBCmp Program result-new MultiSourc...Benchmarks/7zip/7zip-benchmark 79.00 MultiSource/Applications/d/make_dparser 3.00 SingleSource/UnitTests/vla 2.00 MultiSource/Applications/Burg/burg 1.00 MultiSourc.../Applications/JM/lencod/lencod 1.00 MultiSource/Applications/lemon/lemon 1.00 MultiSource/Benchmarks/Bullet/bullet 1.00 MultiSourc...e/Benchmarks/MallocBench/gs/gs 1.00 MultiSourc...gs-C/TimberWolfMC/timberwolfmc 1.00 MultiSourc...Prolangs-C/simulator/simulator 1.00 ``` The size changes are: I'm not sure what's going on with SingleSource/UnitTests/vla.test yet, did not look. ``` $ /build/test-suite/utils/compare.py -m size..text result-{old,new}.json --filter-hash Tests: 1149 Same hash: 907 (filtered out) Remaining: 242 Metric: size..text Program result-old result-new diff test-suite...ingleSource/UnitTests/vla.test 753.00 833.00 10.6% test-suite...marks/7zip/7zip-benchmark.test 1001697.00 966657.00 -3.5% test-suite...ngs-C/simulator/simulator.test 32369.00 32321.00 -0.1% test-suite...plications/d/make_dparser.test 89585.00 89505.00 -0.1% test-suite...ce/Applications/Burg/burg.test 40817.00 40785.00 -0.1% test-suite.../Applications/lemon/lemon.test 47281.00 47249.00 -0.1% test-suite...TimberWolfMC/timberwolfmc.test 250065.00 250113.00 0.0% test-suite...chmarks/MallocBench/gs/gs.test 149889.00 149873.00 -0.0% test-suite...ications/JM/lencod/lencod.test 769585.00 769569.00 -0.0% test-suite.../Benchmarks/Bullet/bullet.test 770049.00 770049.00 0.0% test-suite...HMARK_ANISTROPIC_DIFFUSION/128 NaN NaN nan% test-suite...HMARK_ANISTROPIC_DIFFUSION/256 NaN NaN nan% test-suite...CHMARK_ANISTROPIC_DIFFUSION/64 NaN NaN nan% test-suite...CHMARK_ANISTROPIC_DIFFUSION/32 NaN NaN nan% test-suite...ENCHMARK_BILATERAL_FILTER/64/4 NaN NaN nan% Geomean difference nan% result-old result-new diff count 1.000000e+01 10.00000 10.000000 mean 3.152090e+05 311695.40000 0.006749 std 3.790398e+05 372091.42232 0.036605 min 7.530000e+02 833.00000 -0.034981 25% 4.243300e+04 42401.00000 -0.000866 50% 1.197370e+05 119689.00000 -0.000392 75% 6.397050e+05 639705.00000 -0.000005 max 1.001697e+06 966657.00000 0.106242 ``` I don't have timings though. And now to the code. The basic idea is to completely replace the whole loop. If we can't fully kill it, don't transform. I have left one or two comments in the code, so hopefully it can be understood. Also, there is a few TODO's that i have left for follow-ups: * widening of `memcmp()`/`bcmp()` * step smaller than the comparison size * Metadata propagation * more than two blocks as long as there is still a single backedge? * ??? Reviewers: reames, fhahn, mkazantsev, chandlerc, craig.topper, courbet Reviewed By: courbet Subscribers: hiraditya, xbolva00, nikic, jfb, gchatelet, courbet, llvm-commits, mclow.lists Tags: #llvm Differential Revision: https://reviews.llvm.org/D61144 llvm-svn: 370454
* [NFC] SCEVExpander: add SetCurrentDebugLocation() / ↵Roman Lebedev2019-08-301-2/+10
| | | | | | | | | | | | | | | | | | | | | getCurrentDebugLocation() wrappers Summary: The internal `Builder` is private, which means there is currently no way to set the debuginfo locations for `SCEVExpander`. This only adds the wrappers, but does not use them anywhere. Reviewers: mkazantsev, sanjoy, gberry, jyknight, dneilson Reviewed By: sanjoy Subscribers: javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61007 llvm-svn: 370453
* [clangd] Collecting main file macro expansion locations in ParsedAST.Johan Vikstrom2019-08-303-1/+94
| | | | | | | | | | | | | | Summary: TokenBuffer does not collect macro expansions inside macro arguments which is needed for semantic higlighting. Therefore collects macro expansions in the main file in a PPCallback when building the ParsedAST instead. Reviewers: hokein, ilya-biryukov Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66928 llvm-svn: 370452
* [Tooling] Migrated APIs that take ownership of objects to unique_ptrDmitri Gribenko2019-08-3021-185/+154
| | | | | | | | | | Subscribers: jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66960 llvm-svn: 370451
* dotest: improvements to the pexpect testsPavel Labath2019-08-306-192/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While working on r370054, i've found it frustrating that the test output was compeletely unhelpful in case of failures. Therefore I've decided to improve that. In this I reuse the PExpectTest class, which was one of our mechanisms for running pexpect tests, but which has gotten orhpaned in the mean time. I've replaced the existing send methods with a "expect" method, which I've tried to design so that it has a similar interface to the expect method in regular non-pexpect dotest tests (as it essentially does something very similar). I've kept the ability to dump the transcript of the pexpect communication to stdout in the "trace" mode, as that is a very handy way to figure out what the test is doing. I've also removed the "expect_string" method used in the existing tests -- I've found this to be unhelpful because it hides the message that would be normally displayed by the EOF exception. Although vebose, this message includes some important information, like what strings we were searching for, what were the last bits of lldb output, etc. I've also beefed up the class to automatically disable the debug info test duplication, and auto-skip tests when the host platform does not support pexpect. This patch ports TestMultilineCompletion and TestIOHandlerCompletion to the new class. It also deletes TestFormats as it is not testing anything (definitely not formats) -- it was committed with the test code commented out (r228207), and then the testing code was deleted in r356000. Reviewers: teemperor, JDevlieghere, davide Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D66954 llvm-svn: 370449
* [LiveDebugValues] Insert entry values after bundlesDavid Stenberg2019-08-304-2/+154
| | | | | | | | | | | | | | | | | | | | Summary: Change LiveDebugValues so that it inserts entry values after the bundle which contains the clobbering instruction. Previously it would insert the debug value after the bundle head using insertAfter(), breaking the bundle. Reviewers: djtodoro, NikolaPrica, aprantl, vsk Reviewed By: vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D66888 llvm-svn: 370448
* [clangd] Add .vscode-test to .gitignore.Haojian Wu2019-08-301-0/+1
| | | | | | | | | | | | Reviewers: jvikstrom Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66949 llvm-svn: 370446
* [CodeGen]: fix error message for "=r" asm constraintAlexander Potapenko2019-08-302-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Nico Weber reported that the following code: char buf[9]; asm("" : "=r" (buf)); yields the "impossible constraint in asm: can't store struct into a register" error message, although |buf| is not a struct (see http://crbug.com/999160). Make the error message more generic and add a test for it. Also make sure other tests in x86_64-PR42672.c check for the full error message. Reviewers: eli.friedman, thakis Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66948 llvm-svn: 370444
* vim: add `immarg` keywordSven van Haastregt2019-08-301-0/+1
| | | | | | The `immarg` attribute was added in r355981. llvm-svn: 370443
* gn build: Merge r370441Nico Weber2019-08-301-1/+0
| | | | llvm-svn: 370442
* [ADT] Removed VariadicFunctionDmitri Gribenko2019-08-303-440/+0
| | | | | | | | | | | | | | | Summary: It is not used. It uses macro-based unrolling instead of variadic templates, so it is not idiomatic anymore, and therefore it is a questionable API to keep "just in case". Subscribers: mgorny, dmgreen, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66961 llvm-svn: 370441
* [lldb][NFC] Move Clang-specific flags to ClangUserExpressionRaphael Isemann2019-08-303-19/+18
| | | | | | | | | LLVMUserExpression doesn't use these variables and they are all specific to Clang. Also removes m_const_object as this was actually never used by anyone (and Clang didn't report it as we assigned it in the constructor which seems to count as use). llvm-svn: 370440
* [ELF] Set `referenced` bit of Undefined created by BitcodeFileFangrui Song2019-08-303-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | D64136 and D65584, while fixing STB_WEAK issues and improving our compatibility with ld.bfd, can cause another STB_WEAK problem related to LTO: If %tundef.o has an undefined reference on f, and %tweakundef.o has a weak undefined reference on f, %tdef.o has a definition of f ``` ld.lld %tundef.o %tweakundef.o --start-lib %tdef.o --end-lib ``` 1) `%tundef.o` doesn't set the `referenced` bit. 2) `%weakundef.o` changes the binding from STB_GLOBAL to STB_WEAK 3) `%tdef.o` is not fetched because the binding is weak. Step (1) is incorrect. This patch sets the `referenced` bit of Undefined created by bitcode files. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66992 llvm-svn: 370437
* [LLD] [COFF] Support merging resource object filesMartin Storsjo2019-08-3012-43/+477
| | | | | | | | | | | | | | | | | | | | | | | | Extend WindowsResourceParser to support using a ResourceSectionRef for loading resources from an object file. Only allow merging resource object files in mingw mode; keep the existing error on multiple resource objects in link mode. If there only is one resource object file and no .res resources, don't parse and recreate the .rsrc section, but just link it in without inspecting it. This allows users to produce any .rsrc section (outside of what the parser supports), just like before. (I don't have a specific need for this, but it reduces the risk of this new feature.) Separate out the .rsrc section chunks in InputFiles.cpp, and only include them in the list of section chunks to link if we've determined that there only was one single resource object. (We need to keep other chunks from those object files, as they can legitimately contain other sections as well, in addition to .rsrc section chunks.) Differential Revision: https://reviews.llvm.org/D66824 llvm-svn: 370436
* [WindowsResource] Remove use of global variables in WindowsResourceParserMartin Storsjo2019-08-302-70/+62
| | | | | | | | | | | | | | | | Instead of updating a global variable counter for the next index of strings and data blobs, pass along a reference to actual data/string vectors and let the TreeNode insertion methods add their data/strings to the vectors when a new entry is needed. Additionally, if the resource tree had duplicates, that were ignored with -force:multipleres in lld, we no longer store all versions of the duplicated resource data, now we only keep the one that actually ends up referenced. Differential Revision: https://reviews.llvm.org/D66823 llvm-svn: 370435
* [WindowsResource] Avoid duplicating the input filenames for each resource. NFC.Martin Storsjo2019-08-301-4/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D66821 llvm-svn: 370434
* [COFF] Add a ResourceSectionRef method for getting resource contentsMartin Storsjo2019-08-306-1/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows llvm-readobj to print the contents of each resource when printing resources from an object file or executable, like it already does for plain .res files. This requires providing the whole COFFObjectFile to ResourceSectionRef. This supports both object files and executables. For executables, the DataRVA field is used as is to look up the right section. For object files, ideally we would need to complete linking of them and fix up all relocations to know what the DataRVA field would end up being. In practice, the only thing that makes sense for an RVA field is an ADDR32NB relocation. Thus, find a relocation pointing at this field, verify that it has the expected type, locate the symbol it points at, look up the section the symbol points at, and read from the right offset in that section. This works both for GNU windres object files (which use one single .rsrc section, with all relocations against the base of the .rsrc section, with the original value of the DataRVA field being the offset of the data from the beginning of the .rsrc section) and cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections, and one symbol per data entry, with the original pre-relocated DataRVA field being set to zero). Differential Revision: https://reviews.llvm.org/D66820 llvm-svn: 370433
* [MIPS GlobalISel] Lower uitofpPetar Avramovic2019-08-303-1/+493
| | | | | | | | Add custom lowering for G_UITOFP for MIPS32. Differential Revision: https://reviews.llvm.org/D66930 llvm-svn: 370432
* [MIPS GlobalISel] Lower fptouiPetar Avramovic2019-08-305-0/+536
| | | | | | | | | | Add lower for G_FPTOUI. Algorithm is similar to the SDAG version in TargetLowering::expandFP_TO_UINT. Lower G_FPTOUI for MIPS32. Differential Revision: https://reviews.llvm.org/D66929 llvm-svn: 370431
* [CodeGen] Fix lowering for returning the result of an extractvalueDan Gohman2019-08-302-1/+201
| | | | | | | | | | | | | | When the number of return values exceeds the number of registers available, SelectionDAGBuilder::visitRet transforms a function's return to use a pointer to a buffer to hold return values. When the returned value is an operator such as extractvalue, the value may have a non-zero result number. Add that number to the indexing when obtaining the values to store. This fixes https://bugs.llvm.org/show_bug.cgi?id=43132. Differential Revision: https://reviews.llvm.org/D66978 llvm-svn: 370430
* [clangd] Add distinct highlightings for static fields and methodsNathan Ridge2019-08-304-14/+33
| | | | | | | | | | | | | | Reviewers: hokein, ilya-biryukov, jvikstrom Reviewed By: hokein Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66828 llvm-svn: 370429
* [PowerPC][NFC] Use inline Subtarget->isPPC64()Jinsong Ji2019-08-301-7/+6
| | | | | | To be consistent with all the other instances. llvm-svn: 370428
* [PowerPC][NFC] Use -mtriple in RUN line, remove target triple in tls.llJinsong Ji2019-08-301-4/+4
| | | | | | To avoid confusion, especially when -mtriple are also added for PPC32. llvm-svn: 370427
* [PPC32] Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LOFangrui Song2019-08-302-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike ppc64, which has ADDISgotTprelHA+LDgotTprelL pairs, ppc32 just uses LDgotTprelL32, so it does not make lots of sense to use _LO without a paired _HA. Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO to match GCC, and get better linker relocation check. Note, R_PPC_GOT_TPREL16_{HA,LO} don't have good linker support: (a) lld does not support R_PPC_GOT_TPREL16_{HA,LO}. (b) Top of tree ld.bfd does not support R_PPC_GOT_REL16_HA Initial-Exec -> Local-Exec relaxation: // a.o addis 3, 3, tsd_tls@got@tprel@ha lwz 3, tsd_tls@got@tprel@l(3) add 3, 3, tsd_tls@tls // b.o .section .tdata,"awT"; .globl tsd_tls; tsd_tls: // ld/ld-new a.o b.o internal error, aborting at ../../bfd/elf32-ppc.c:7952 in ppc_elf_relocate_section Reviewed By: adalava Differential Revision: https://reviews.llvm.org/D66925 llvm-svn: 370426
* [clang-scan-deps] NFC, refactor the DependencyScanningWorker to use a consumerAlex Lorenz2019-08-303-43/+117
| | | | | | | | | | | to report the dependencies to the client This will allow the scanner to report modular dependencies to the consumer. This will also allow the scanner to accept regular cc1 clang invocations, e.g. in an implementation of a libclang C API for clang-scan-deps, that I will add follow-up patches for in the future. llvm-svn: 370425
* [X86] Explicitly list all the always trivially rematerializable instructions.Craig Topper2019-08-301-5/+40
| | | | | | | | | Add a default with an llvm_unreachable for anything we don't expect. This seems safer that just blindly returning true for anything missing from the switch. llvm-svn: 370424
* DebugInfo: add CodeView register mapping for ARM NTSaleem Abdulrasool2019-08-301-0/+121
| | | | | | | | Add the core registers and NEON registers mapping to the CodeView register ID. This is sufficient to compile a basic C program with debug info using CodeView debug info. llvm-svn: 370423
* [Modules] Make ReadModuleMapFileBlock errors reliableBruno Cardoso Lopes2019-08-292-9/+11
| | | | | | | | | | | | | | | | | | This prevents a crash when an error should be emitted instead. During implicit module builds, there are cases where ReadASTCore is called with ImportedBy set to nullptr, which breaks expectations in ReadModuleMapFileBlock, leading to crashes. Fix this by improving ReadModuleMapFileBlock to handle ImportedBy correctly. This only happens non deterministically in the wild, when the underlying file system changes while concurrent compiler invocations use implicit modules, forcing rebuilds which see an inconsistent filesystem state. That said, there's no much to do w.r.t. writing tests here. rdar://problem/48828801 llvm-svn: 370422
* [CMake][Fuchsia] Enable experimental pass manager by defaultPetr Hosek2019-08-292-0/+2
| | | | | | | | We plan on using experimental new pass manager for Fuchsia toolchain. Differential Revision: https://reviews.llvm.org/D58214 llvm-svn: 370421
* [clang-scan-deps] reuse the file manager across invocations ofAlex Lorenz2019-08-2911-8/+101
| | | | | | | | | | | | | | | | the dependency scanner on a single worker thread This behavior can be controlled using the new `-reuse-filemanager` clang-scan-deps option. By default the file manager is reused. The added test/ClangScanDeps/symlink.cpp is able to pass with the reused filemanager after the related FileEntryRef changes landed earlier. The test test/ClangScanDeps/subframework_header_dir_symlink.m still fails when the file manager is reused (I run the FileCheck with not to make it PASS). I will address this in a follow-up patch that improves the DirectoryEntry name modelling in the FileManager. llvm-svn: 370420
* Fix silent wrong-code bugs and crashes with designated initialization.Richard Smith2019-08-293-176/+388
| | | | | | | | | | | | | | | | | | | | | We failed to correctly handle the 'holes' left behind by designated initializers in VerifyOnly mode. This would result in us thinking that a designated initialization would be valid, only to find that it is not actually valid when we come to build it. In a +Asserts build, that would assert, and in a -Asserts build, that would silently lose some part of the initialization or crash. With this change, when an InitListExpr contains any designators, we now always build a structured list so that we can track the locations of the 'holes' that we need to go back and fill in. We could in principle do better: we only need the structured form if there is a designator that jumps backwards (and can otherwise check for the holes as we progress through the initializer list), but dealing with that turns out to be rather complicated, so it's not done as part of this patch. llvm-svn: 370419
* Refactor InitListChecker to check only a single (explicit) initializerRichard Smith2019-08-292-48/+15
| | | | | | | | | | list, rather than recursively checking multiple lists in C. This simplification is in preparation for making InitListChecker maintain more state that's specific to the explicit initializer list, particularly when handling designated initialization. llvm-svn: 370418
* Refactor InitListChecker to make it a bit clearer that hasError is onlyRichard Smith2019-08-291-44/+36
| | | | | | | | | | set to true in VerifyOnly mode in cases where it's also set to true when actually building the initializer list. Add FIXMEs for the two cases where that's not true. No functionality change intended. llvm-svn: 370417
* [WebAssembly] Implement NO_STRIPDan Gohman2019-08-297-7/+26
| | | | | | | | | | | | | This patch implements support for the NO_STRIP flag, which will allow __attribute__((used)) to be implemented. This accompanies https://reviews.llvm.org/D62542, which moves to setting the NO_STRIP flag, and will continue to set EXPORTED for Emscripten targets for compatibility. Differential Revision: https://reviews.llvm.org/D66968 llvm-svn: 370416
OpenPOWER on IntegriCloud