summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [SampleProfile] Skip intrinsic calls when visiting callsites in ↵Andrea Di Biagio2017-04-181-1/+1
| | | | | | | | | | | | | | InlineHotFunctions. Before this patch, we always called method 'findCalleeFunctionSamples()' on intrinsic calls. However, intrinsic calls like llvm.dbg.value() are not viable candidates for obvious reasons. No functional change intended. Differential Revision: https://reviews.llvm.org/D32008 llvm-svn: 300541
* [TableGen] Fix MSVC warning that occurs in TableGen generated functionAlex Lorenz2017-04-181-1/+3
| | | | | | This should fix the Windows buildbot failure that happened after r300539. llvm-svn: 300540
* Add #pragma clang attributeAlex Lorenz2017-04-1840-52/+3072
| | | | | | | | | | | | | | The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300539
* Revert "[GlobalISel] Support vector-of-pointers in LLT"Kristof Beyls2017-04-187-213/+69
| | | | | | | | | | | | | | | | This reverts r300535 and r300537. The newly added tests in test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll produces slightly different code between LLVM versions being built with different compilers. E.g., dependent on the compiler LLVM is built with, either one of the following can be produced: remark: <unknown>:0:0: unable to legalize instruction: %vreg0<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg2; (in function: vector_of_pointers_extractelement) remark: <unknown>:0:0: unable to legalize instruction: %vreg2<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg0; (in function: vector_of_pointers_extractelement) Non-determinism like this is clearly a bad thing, so reverting this until I can find and fix the root cause of the non-determinism. llvm-svn: 300538
* Fix gcc build after r300535.Kristof Beyls2017-04-181-8/+8
| | | | llvm-svn: 300537
* [ARM] Check for correct HW div when lowering divmodDiana Picus2017-04-182-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For subtargets that use the custom lowering for divmod, e.g. gnueabi, we used to check if the subtarget has hardware divide and then lower to a div-mul-sub sequence if true, or to a libcall if false. However, judging by the usage of hasDivide vs hasDivideInARMMode, it seems that hasDivide only refers to Thumb. For instance, in the ARMTargetLowering constructor, the code that specifies whether to use libcalls for (S|U)DIV looks like this: bool hasDivide = Subtarget->isThumb() ? Subtarget->hasDivide() : Subtarget->hasDivideInARMMode(); In the case of divmod for arm-gnueabi, using only hasDivide() to determine what to do means that instead of lowering to __aeabi_idivmod to get the remainder, we lower to div-mul-sub and then further lower the div to __aeabi_idiv. Even worse, if we have hardware divide in ARM but not in Thumb, we generate a libcall instead of using it (this is not an issue in practice since AFAICT none of the cores that we support have hardware divide in ARM but not Thumb). This patch fixes the code dealing with custom lowering to take into account the mode (Thumb or ARM) when deciding whether or not hardware division is available. Differential Revision: https://reviews.llvm.org/D32005 llvm-svn: 300536
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-187-69/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300535
* [clang-tidy] Add a clang-tidy check for possible inefficient vector operationsHaojian Wu2017-04-188-1/+400
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The "performance-inefficient-vector-operation" check finds vector oprations in for-loop statements which may cause multiple memory reallocations. This is the first version, only detects typical for-loop: ``` std::vector<int> v; for (int i = 0; i < n; ++i) { v.push_back(i); } // or for (int i = 0; i < v2.size(); ++i) { v.push_back(v2[i]); } ``` We can extend it to handle more cases like for-range loop in the future. Reviewers: alexfh, aaron.ballman Reviewed By: aaron.ballman Subscribers: zaks.anna, Eugene.Zelenko, mgorny, cfe-commits, djasper Differential Revision: https://reviews.llvm.org/D31757 llvm-svn: 300534
* Emit benchmark tests into the benchmarks build directory, not lib/Eric Fiselier2017-04-181-1/+3
| | | | llvm-svn: 300533
* test commitLeslie Zhai2017-04-181-0/+1
| | | | llvm-svn: 300532
* [sanitizer] Don't include <linux/user.h> in ↵Maxim Ostapenko2017-04-181-10/+6
| | | | | | | | | | | | | | | | | | | | | | | sanitizer_stoptheworld_linux_libcdep.cc on ARM Android Turned out that adding defined(_arm_) in sanitizer_stoptheworld_linux_libcdep.cc breaks android arm with some toolchains. .../llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:36:11: fatal error: 'linux/user.h' file not found # include <linux/user.h> // for pt_regs ^ 1 error generated. Context: #if SANITIZER_ANDROID && defined(__arm__) # include <linux/user.h> // for pt_regs #else This patch removes corresponding #if SANITIZER_ANDROID && defined(__arm__) and a bit rearranges adjacent сode. Differential Revision: https://reviews.llvm.org/D32128 llvm-svn: 300531
* Update google benchmarkEric Fiselier2017-04-1841-159/+1227
| | | | llvm-svn: 300530
* Assert that a valid operator new/delete signature is always found by the ↵Eric Fiselier2017-04-181-4/+3
| | | | | | coroutine body llvm-svn: 300529
* Speculatively attempt to fix bot failures caused by recent coroutine changes.Eric Fiselier2017-04-181-3/+6
| | | | llvm-svn: 300528
* [APInt] Cleanup the reverseBits slow case a little.Craig Topper2017-04-181-6/+4
| | | | | | Use lshrInPlace. Use single bit extract and operator|=(uint64_t) to avoid a few temporary APInts. llvm-svn: 300527
* [APInt] Make operator<<= shift in place. Improve the implementation of ↵Craig Topper2017-04-183-92/+74
| | | | | | tcShiftLeft and use it to implement operator<<=. llvm-svn: 300526
* [XRay][compiler-rt] Use emulated TSC when CPU supports rdtscp, but cannot ↵Douglas Yung2017-04-183-6/+23
| | | | | | | | | | | | | | | | | | | | | determine the CPU frequency A problem arises if a machine supports the rdtscp instruction, but the processor frequency cannot be determined by the function getTSCFrequency(). In this case, we want to use the emulated TSC instead. This patch implements that by adding a call to getTSCFrequency() from probeRequiredCPUFeatures(), and the function only returns true if both the processor supports rdtscp and the CPU frequency can be determined. This should fix PR32620. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32067 llvm-svn: 300525
* [coroutines] Fix building of new/delete expressions when ↵Eric Fiselier2017-04-184-12/+152
| | | | | | | | | | | | | | | | | | | | | | get_return_object_on_allocation_failure() is present. Summary: This patch implements [dcl.fct.def.coroutine]p8: > The unqualified-id get_return_object_on_allocation_failure is looked up in the scope of > class P by class member access lookup (3.4.5). If a declaration is found, ..., and if a > global allocation function is selected, the ::operator new(size_t, nothrow_t) form shall be used. > [...] > The allocation function used in this case must have a non-throwing noexcept-specification. Reviewers: GorNishanov, rsmith, majnemer, aaron.ballman Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31562 llvm-svn: 300524
* Debug Info: Remove special-casing of indirect function argument handling.Adrian Prantl2017-04-184-33/+15
| | | | | | | | | | | | LLVM has changed the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. https://bugs.llvm.org/show_bug.cgi?id=32382 rdar://problem/31205000 llvm-svn: 300523
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-1837-178/+381
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* [asan] Fixup for r300483 (which is a fixup for r300473).Evgeniy Stepanov2017-04-181-4/+5
| | | | | | Sanitizer Printf() does not know about %lu. llvm-svn: 300521
* Add const to a const method. NFCGeorge Burgess IV2017-04-182-2/+2
| | | | llvm-svn: 300520
* TestStaticVariables still fails on Linux.Jim Ingham2017-04-181-0/+2
| | | | llvm-svn: 300519
* [Target] Use hasOneUse() instead of getNumUses().Davide Italiano2017-04-181-1/+1
| | | | | | | The latter does a liner scan over a linked list, therefore is much more expensive. llvm-svn: 300518
* This test is succeeding on macOS with clang.Jim Ingham2017-04-181-6/+1
| | | | llvm-svn: 300517
* Allow a standard library to implement conditional noexcept for optional and ↵Billy Robert O'Neal III2017-04-182-6/+14
| | | | | | | | | | unique_ptr hash functions. These tests were unconditionally asserting that optional and unique_ptr declare throwing hashes, but MSVC++ implements conditional noexcept forwarding that of the underlying hash function. As a result we were failing these tests but there's nothing forbidding strengthening noexcept in that way. Changed the ASSERT_NOT_NOEXCEPT asserts to use types which themselves have non-noexcept hash functions. llvm-svn: 300516
* Fix mishandling of escaped newlines followed by newlines or nuls.Richard Smith2017-04-174-19/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, if an escaped newline was followed by a newline or a nul, we'd lex the escaped newline as a bogus space character. This led to a bunch of different broken corner cases: For the pattern "\\\n\0#", we would then have a (horizontal) space whose spelling ends in a newline, and would decide that the '#' is at the start of a line, and incorrectly start preprocessing a directive in the middle of a logical source line. If we were already in the middle of a directive, this would result in our attempting to process multiple directives at the same time! This resulted in crashes, asserts, and hangs on invalid input, as discovered by fuzz-testing. For the pattern "\\\n" at EOF (with an implicit following nul byte), we would produce a bogus trailing space character with spelling "\\\n". This was mostly harmless, but would lead to clang-format getting confused and misformatting in rare cases. We now produce a trailing EOF token with spelling "\\\n", consistent with our handling for other similar cases -- an escaped newline is always part of the token containing the next character, if any. For the pattern "\\\n\n", this was somewhat more benign, but would produce an extraneous whitespace token to clients who care about preserving whitespace. However, it turns out that our lexing for line comments was relying on this bug due to an off-by-one error in its computation of the end of the comment, on the slow path where the comment might contain escaped newlines. llvm-svn: 300515
* Object: Shrink the size of irsymtab::Symbol by a word. NFCI.Peter Collingbourne2017-04-172-35/+42
| | | | | | | | | | Instead of storing an UncommonIndex on the Symbol, use a flag bit to store whether the Symbol has an Uncommon. This shrinks Chromium's .bc files (after D32061) by about 1%. Differential Revision: https://reviews.llvm.org/D32070 llvm-svn: 300514
* Rename coroutine warning when unhandled_exception() is missingEric Fiselier2017-04-174-5/+22
| | | | llvm-svn: 300513
* Unify the common code in the ios, tvos, watchos platforms into a singleJason Molenda2017-04-1711-2178/+907
| | | | | | | | | PlatformRemoveDarwinDevice class, subclassed to those three so they can provide their specific information. <rdar://problem/30159764> llvm-svn: 300512
* Revert r300504 - [coroutines] Fix rebuilding of implicit and dependent ↵Eric Fiselier2017-04-174-152/+12
| | | | | | | | | coroutine statements. I have no idea what's happening here. The tests that fail on all of the bots pass on my machine. Further investigation needed. llvm-svn: 300511
* Work around GCC 4.9 bug regarding default initialization of const variablesEric Fiselier2017-04-171-13/+15
| | | | llvm-svn: 300510
* [ubsan] Skip null checks if they are constant-folded awayVedant Kumar2017-04-172-9/+19
| | | | | | | | | | | | | | | | | | | | | The IR builder can constant-fold null checks if the pointer operand points to a constant. If the "is-non-null" check is folded away to "true", don't emit the null check + branch. Testing: check-clang, check-ubsan. This slightly reduces the amount of null checks we emit when compiling X86ISelLowering.cpp. Here are the numbers from patched/unpatched clangs based on r300371. ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 25251 | | patched, -O0 | 23925 | (-5.3%) ------------------------------------- llvm-svn: 300509
* [ubsan] Skip null checks on pointers to the start of an allocaVedant Kumar2017-04-172-8/+30
| | | | | | | | | | | | | | | | | | | | Pointers to the start of an alloca are non-null, so we don't need to emit runtime null checks for them. Testing: check-clang, check-ubsan. This significantly reduces the amount of null checks we emit when compiling X86ISelLowering.cpp. Here are the numbers from patched / unpatched clangs based on r300371. ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 45439 | | patched, -O0 | 25251 | (-44.4%) ------------------------------------- llvm-svn: 300508
* Build SymbolMap in SampleProfileLoader to help matchin function names with ↵Dehao Chen2017-04-173-1/+81
| | | | | | | | | | | | | | | | suffix. Summary: If there is suffix added in the function name (e.g. module hash added by thinLTO), we will not be able to find a match in profile as the suffix does not exist in profile. This patch build a map from function name to Function *. The map includes the entry for the stripped function name so that inlineHotFunctions can find the corresponding function to promote/inline. Reviewers: davidxl, dnovillo, tejohnson Reviewed By: davidxl Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D31952 llvm-svn: 300507
* Change the testcase tail-merge-after-mbp.ll to tail-merge-after-mbp.mirHaicheng Wu2017-04-172-94/+105
| | | | | | Differential Revision: https://reviews.llvm.org/D32037 llvm-svn: 300506
* [SimplifyCFG] Use hasNUses instead of comparing getNumUses to a constant."Craig Topper2017-04-171-1/+1
| | | | | | The use list is a linked list so getNumUses requires a linear scan through the whole list. hasNUses will stop scanning at N and see if that is the end. llvm-svn: 300505
* [coroutines] Fix rebuilding of implicit and dependent coroutine statements.Eric Fiselier2017-04-174-12/+152
| | | | | | | | | | | | | | | | | | | Summary: Certain implicitly generated coroutine statements, such as the calls to 'return_value()' or `return_void()` or `get_return_object_on_allocation_failure()`, cannot be built until the promise type is no longer dependent. This means they are not built until after the coroutine body statement has been transformed. This patch fixes an issue where these statements would never be built for coroutine templates. It also fixes a small issue where diagnostics about `get_return_object_on_allocation_failure()` were incorrectly suppressed. Reviewers: rsmith, majnemer, GorNishanov, aaron.ballman Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31487 llvm-svn: 300504
* [APInt] Merge the multiword code from lshrInPlace and tcShiftRight into a ↵Craig Topper2017-04-173-78/+63
| | | | | | | | | | | | single implementation This merges the two different multiword shift right implementations into a single version located in tcShiftRight. lshrInPlace now calls tcShiftRight for the multiword case. I retained the memmove fast path from lshrInPlace and used a memset for the zeroing. The for loop is basically tcShiftRight's implementation with the zeroing and the intra-shift of 0 removed. Differential Revision: https://reviews.llvm.org/D32114 llvm-svn: 300503
* [WebAssembly] Fix WebAssemblyOptimizeReturned after r300367Jacob Gravelle2017-04-172-1/+32
| | | | | | | | | | | | | | | | Summary: Refactoring changed paramHasAttr(1 + i) to paramHasAttr(0), fix that to paramHasAttr(i). Add more tests to WebAssemblyOptimizeReturned that catch that regression. Reviewers: dschuff Subscribers: jfb, sbc100, llvm-commits Differential Revision: https://reviews.llvm.org/D32136 llvm-svn: 300502
* clang-cl: Support the /Zc:twoPhase[-] command-line option (PR32680)Hans Wennborg2017-04-172-0/+9
| | | | | | | | | It sounds like MSVC is adding support for two-phase name lookup in a future version, enabled by this flag (see bug). Differential Revision: https://reviews.llvm.org/D32138 llvm-svn: 300501
* [SCEV] Fix another unused variable warning in release builds.Benjamin Kramer2017-04-171-0/+1
| | | | llvm-svn: 300500
* Fix an unused variable error in rL300494.Wei Mi2017-04-171-0/+1
| | | | llvm-svn: 300499
* [libFuzzer] experimental option -cleanse_crash: tries to replace all bytes ↵Kostya Serebryany2017-04-175-0/+85
| | | | | | in a crash reproducer with garbage, while still preserving the crash llvm-svn: 300498
* Revert "Address http://bugs.llvm.org/pr30994 so that a non-friend can ↵Benjamin Kramer2017-04-174-34/+13
| | | | | | | | | properly replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp." This reverts commit r300443. Breaks compiling libc++ with modules in some configurations. llvm-svn: 300497
* Add a linker script to version LLVM symbolsSylvestre Ledru2017-04-173-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a very simple linker script to version the lib's symbols and thus trying to avoid crashes if an application loads two different LLVM versions (as long as they do not share data between them). Note that we deliberately *don't* make LLVM_5.0 depend on LLVM_4.0: they're incompatible and the whole point of this patch is to tell the linker that. Avoid unexpected crashes when two LLVM versions are used in the same process. Author: Rebecca N. Palmer <rebecca_palmer@zoho.com> Author: Lisandro Damían Nicanor Pérez Meyer <lisandro@debian.org> Author: Sylvestre Ledru <sylvestre@debian.org> Bug-Debian: https://bugs.debian.org/848368 Reviewers: beanz, rnk Reviewed By: rnk Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D31524 llvm-svn: 300496
* [InstCombine] Matchers work with both ConstExpr and Instructions.Davide Italiano2017-04-172-2/+24
| | | | | | | | | | So, `cast<Instruction>` is not guaranteed to succeed. Change the code so that we create a new constant and use it in the newly created instruction, as it's done in other places in InstCombine. OK'ed by Sanjay/Craig. Fixes PR32686. llvm-svn: 300495
* [SCEV] Add a local cache for getZeroExtendExpr and getSignExtendExpr to preventWei Mi2017-04-173-61/+217
| | | | | | | | | | | | | | | | | | the exponential behavior. The patch is to fix PR32043. Functions getZeroExtendExpr and getSignExtendExpr may call themselves recursively more than once. This is potentially a 2^N complexity behavior. The exponential behavior was not commonly exposed before because of existing global cache mechnism like UniqueSCEVs or some early return mechanism when flags FlagNSW or FlagNUW are seen. However, we still have case which can expose the exponential behavior, like the case in PR32043, so we add a local cache in getZeroExtendExpr and getSignExtendExpr. If the input of the functions -- SCEV and type pair have been seen before, we can find the extended expression directly in the local cache. Differential Revision: https://reviews.llvm.org/D30350 llvm-svn: 300494
* [InstSimplify] add/move tests for (icmp X, C1 & icmp X, C2); NFCSanjay Patel2017-04-172-20/+2912
| | | | | | We simplify based on range intersection, but we're missing folds. llvm-svn: 300493
* Update the test to fix the buildbot failure introduced by r300486 (NFC)Dehao Chen2017-04-171-12/+12
| | | | llvm-svn: 300492
OpenPOWER on IntegriCloud