summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [CMake] Use CMake's default RPATH for the unit testsDiana Picus2016-09-071-5/+3
| | | | | | | | | | | | | | | In the top-level CMakeLists.txt, we set CMAKE_BUILD_WITH_INSTALL_RPATH to ON, and then for the unit tests we set it to <test>/../../lib. This works for tests that live in unittest/<whatever>, but not for those that live in subdirectories e.g. unittest/Transforms/IPO or unittest/ExecutionEngine/Orc. When building with BUILD_SHARED_LIBRARIES, such tests don't manage to find their libraries. Since the tests are run from the build directory, it makes sense to set their RPATH for the build tree, rather than the install tree. This is the default in CMake since 2.6, so all we have to do is set CMAKE_BUILD_WITH_INSTALL_RPATH to OFF for the unit tests. llvm-svn: 280791
* [SimplifyCFG] Check PHI uses more accuratelyJames Molloy2016-09-072-1/+28
| | | | | | | | PR30292 showed a case where our PHI checking wasn't correct. We were checking that all values were used by the same PHI before deciding to sink, but we weren't checking that the incoming values for that PHI were what we expected. As a result, we had to bail out after block splitting which caused us to never reach a steady state in SimplifyCFG. Fixes PR30292. llvm-svn: 280790
* [PowerPC] Fix address-offset folding for plain addiHal Finkel2016-09-072-15/+78
| | | | | | | | | | | | | | | | | | | | | | | When folding an addi into a memory access that can take an immediate offset, we were implicitly assuming that the existing offset was zero. This was incorrect. If we're dealing with an addi with a plain constant, we can add it to the existing offset (assuming that doesn't overflow the immediate, etc.), but if we have anything else (i.e. something that will become a relocation expression), we'll go back to requiring the existing immediate offset to be zero (because we don't know what the requirements on that relocation expression might be - e.g. maybe it is paired with some addis in some relevant way). On the other hand, when dealing with a plain addi with a regular constant immediate, the alignment restrictions (from the TOC base pointer, etc.) are irrelevant. I've added the test case from PR30280, which demonstrated the bug, but also demonstrates a missed optimization opportunity (i.e. we don't need the memory accesses at all). Fixes PR30280. llvm-svn: 280789
* Support ABSOLUE keyword in symbol assignmentsEugene Leviant2016-09-073-30/+62
| | | | | | | | | | | | This patch allows making section defined symbols absolute: .foo : { begin_foo = ABSOLUTE(.); *(.foo) } Differential revision: https://reviews.llvm.org/D24135 llvm-svn: 280788
* OpenCL: Defining __ENDIAN_LITTLE__ and fix target endiannessMatt Arsenault2016-09-075-22/+9
| | | | | | | | | OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets. The default for targets was also apparently big endian, so AMDGPU was incorrectly reported as big endian. Set this from the triple so targets don't have another place to set the endianness. llvm-svn: 280787
* Fix whitespace issuesMatt Arsenault2016-09-071-2/+1
| | | | | | ^M and extra space llvm-svn: 280786
* AVX512F: FMA intrinsic + FNEG - sequence optimizationElena Demikhovsky2016-09-072-110/+117
| | | | | | | | | | | The previous commit (r280368 - https://reviews.llvm.org/D23313) does not cover AVX-512F, KNL set. FNEG(x) operation is lowered to (bitcast (vpxor (bitcast x), (bitcast constfp(0x80000000))). It happens because FP XOR is not supported for 512-bit data types on KNL and we use integer XOR instead. I added pattern match for integer XOR. Differential Revision: https://reviews.llvm.org/D24221 llvm-svn: 280785
* AMDGPU: Make some scalar instructions commutableMatt Arsenault2016-09-071-2/+9
| | | | llvm-svn: 280784
* Remove unnecessary call to getAllocatableRegClassMatt Arsenault2016-09-073-18/+19
| | | | | | | | This reapplies r252565 and r252674, effectively reverting r252956. This allows VS_32/VS_64 to be unallocatable like they should be. llvm-svn: 280783
* [X86] Add hasSideEffects=0 to some instructions.Craig Topper2016-09-072-3/+5
| | | | llvm-svn: 280782
* [AVX-512] Add support for commuting masked instructions in ↵Craig Topper2016-09-072-1/+75
| | | | | | findCommutedOpIndices. The default implementation doesn't skip the mask input or the preserved input. llvm-svn: 280781
* Avoid compile error by giving the test type a user defined default constructorEric Fiselier2016-09-071-1/+1
| | | | llvm-svn: 280780
* Fix PR#30303 - no matching function for call to '__ptr_in_range'Marshall Clow2016-09-075-1/+47
| | | | llvm-svn: 280779
* Revert "CodeGen: ensure that libcalls are always AAPCS CC"Saleem Abdulrasool2016-09-076-182/+178
| | | | | | | This reverts SVN r280683. Revert until I figure out why this is breaking lli tests. llvm-svn: 280778
* Improve constexpr tests for std::anyEric Fiselier2016-09-071-9/+9
| | | | llvm-svn: 280777
* Fix clang's handling of the copy performed in the second phase of classRichard Smith2016-09-0711-133/+180
| | | | | | | | | | | | | | | | | | | | | | | copy-initialization. We previously got this wrong in a couple of ways: - we only looked for copy / move constructors and constructor templates for this copy, and thus would fail to copy in cases where doing so should use some other constructor (but see core issue 670), - we mishandled the special case for disabling user-defined conversions that blocks infinite recursion through repeated application of a copy constructor (applying it in slightly too many cases) -- though as far as I can tell, this does not ever actually affect the result of overload resolution, and - we misapplied the special-case rules for constructors taking a parameter whose type is a (reference to) the same class type by incorrectly assuming that only happens for copy/move constructors (it also happens for constructors instantiated from templates and those inherited from base classes). These changes should only affect strange corner cases (for instance, where the copy constructor exists but has a non-const-qualified parameter type), so for the most part it only causes us to produce more 'candidate' notes, but see the test changes for other cases whose behavior is affected. llvm-svn: 280776
* Fix PR30260 - optional<const T> not working.Eric Fiselier2016-09-079-14/+113
| | | | | | | | | | This patch fixes PR30260 by using a (void*) cast on the placement argument to placement new to casts away the const. See also http://llvm.org/PR30260. As a drive by change this patch also changes the header guard for <experimental/optional> to _LIBCPP_EXPERIMENTAL_OPTIONAL from _LIBCPP_OPTIONAL. llvm-svn: 280775
* Fix typo in comment, NFCNick Lewycky2016-09-071-1/+1
| | | | llvm-svn: 280774
* Enable installation of libc++experimental by default.Eric Fiselier2016-09-072-2/+5
| | | | | | | | | | | | When libc++experimental was originally created it was empty and therefore there was no reason to install it. Now that the library contains <experimental/memory_resource> and <experimental/filesystem> there is a good reason to install it. Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true. llvm-svn: 280773
* [LTO] Rename variables to be more explicative.Davide Italiano2016-09-071-29/+30
| | | | | | Thanks to Mehdi for the suggestion! llvm-svn: 280772
* Improve CMake output when registering benchmarksEric Fiselier2016-09-071-1/+1
| | | | llvm-svn: 280771
* [opt] Remove an unused argument to runPassPipeline().Davide Italiano2016-09-073-3/+3
| | | | | | I have plans to use this API also in libLTO (and maybe lld). llvm-svn: 280770
* Re-add "Make FieldList records print as a YAML sequence"Zachary Turner2016-09-064-1089/+1138
| | | | | | | | | | | | This was originally submitted in r280549, and reverted in r280577 due to breaking one MSVC buildbot. The issue is that MSVC 2013 doesn't synthesize move constructors. So even though i was writing std::move(A) it was copying it, leading to a bogus ArrayRef. The solution here is to simply remove the std::vector<> from the type, since it is unused and unnecessary. This way the ArrayRef continues to point into the original memory backing the CVType. llvm-svn: 280769
* [scan-build-py] Increase precision of timestamp in report directory nameDevin Coughlin2016-09-062-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit improves compatibility with the perl version of scan-build. The perl version of scan-build produces output report directories with increasing lexicographic ordering. This ordering is relied on by the CmpRuns.py tool in utils/analyzer when comparing results for build commands with multiple steps. That tool tries to line up the output directory for each step between different runs of the analyzer based on the increasing directory name. The python version of scan-build uses file.mkdtemp() with a time stamp prefix to create report directories. The timestamp has a 1-second precision. This means that when analysis of a single build step takes less than a second the ordering property that CmpRuns.py expects will sometimes not hold, depending on the timing and the random suffix generated by mkdtemp(). Ultimately this causes CmpRuns to incorrectly correlate results from build steps and report spurious differences between runs. This commit increases the precision of the timestamp used in scan-build-py to the microsecond level. This approach still has the same underlying issue -- but in practice analysis of any build step is unlikely to take less than a millisecond. Differential Revision: https://reviews.llvm.org/D24163 llvm-svn: 280768
* [DAGCombine] More fixups to SETCC legality checking (visitANDLike/visitORLike)Hal Finkel2016-09-062-28/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I might have called this "r246507, the sequel". It fixes the same issue, as the issue has cropped up in a few more places. The underlying problem is that isSetCCEquivalent can pick up select_cc nodes with a result type that is not legal for a setcc node to have, and if we use that type to create new setcc nodes, nothing fixes that (and so we've violated the contract that the infrastructure has with the backend regarding setcc node types). Fixes PR30276. For convenience, here's the commit message from r246507, which explains the problem is greater detail: [DAGCombine] Fixup SETCC legality checking SETCC is one of those special node types for which operation actions (legality, etc.) is keyed off of an operand type, not the node's value type. This makes sense because the value type of a legal SETCC node is determined by its operands' value type (via the TLI function getSetCCResultType). When the SDAGBuilder creates SETCC nodes, it either creates them with an MVT::i1 value type, or directly with the value type provided by TLI.getSetCCResultType. The first problem being fixed here is that DAGCombine had several places querying TLI.isOperationLegal on SETCC, but providing the return of getSetCCResultType, instead of the operand type directly. This does not mean what the author thought, and "luckily", most in-tree targets have SETCC with Custom lowering, instead of marking them Legal, so these checks return false anyway. The second problem being fixed here is that two of the DAGCombines could create SETCC nodes with arbitrary (integer) value types; specifically, those that would simplify: (setcc a, b, op1) and|or (setcc a, b, op2) -> setcc a, b, op3 (which is possible for some combinations of (op1, op2)) If the operands of the and|or node are actual setcc nodes, then this is not an issue (because the and|or must share the same type), but, the relevant code in DAGCombiner::visitANDLike and DAGCombiner::visitORLike actually calls DAGCombiner::isSetCCEquivalent on each operand, and that function will recognise setcc-like select_cc nodes with other return types. And, thus, when creating new SETCC nodes, we need to be careful to respect the value-type constraint. This is even true before type legalization, because it is quite possible for the SELECT_CC node to have a legal type that does not happen to match the corresponding TLI.getSetCCResultType type. To be explicit, there is nothing that later fixes the value types of SETCC nodes (if the type is legal, but does not happen to match TLI.getSetCCResultType). Creating SETCCs with an MVT::i1 value type seems to work only because, either MVT::i1 is not legal, or it is what TLI.getSetCCResultType returns if it is legal. Fixing that is a larger change, however. For the time being, restrict the relevant transformations to produce only SETCC nodes with a value type matching TLI.getSetCCResultType (or MVT::i1 prior to type legalization). Fixes PR24636. llvm-svn: 280767
* Simplify a boolean expression by using the De Morgan's law.Rui Ueyama2016-09-061-1/+1
| | | | llvm-svn: 280766
* [llvm-cov] Use colors consistently in the summaryVedant Kumar2016-09-061-32/+32
| | | | | | | | Use the same color for counts and percentages. There doesn't seem to be a reason for them to be different, and the summary looks more consistent this way. llvm-svn: 280765
* [llvm-cov] Clean up the summary class, delete dead code (NFC)Vedant Kumar2016-09-063-59/+59
| | | | llvm-svn: 280764
* Revert "Fix tests on Windows."Zachary Turner2016-09-061-2/+2
| | | | | | | | This reverts commit 9b757b6e3946311802972409f38c6cefbea917b3. This seems to cause strange breakages about on Ubuntu. llvm-svn: 280763
* Explicitly require DominatorTreeAnalysis pass for instsimplify pass.Dehao Chen2016-09-061-5/+6
| | | | | | | | | | | | Summary: DominatorTreeAnalysis is always required by instsimplify. Reviewers: danielcdh, davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24173 llvm-svn: 280760
* Fix tests on Windows.Zachary Turner2016-09-061-2/+2
| | | | | | | | | This wasn't actually a problem with the reformat, but rather a problem with Visual Studio 2015 Update 3, which uses some c++14 features in its standard libraries. So we had to change -std=c++11 to -std=c++14. llvm-svn: 280759
* Put the LLVM_ALIGNAS directive in the right place.Zachary Turner2016-09-061-2/+2
| | | | llvm-svn: 280758
* Make LLDB compile on Windows after the reformat.Zachary Turner2016-09-062-2/+10
| | | | | | | | | | | | | | | | Most of these issues arose as a result of header re-ordering, but it turned up a real bug, which is that MSVC doesn't support __attribute__((packed)) or __attribute__((aligned)). This was working before because there's a Windows header that #defines __attribute__(x) to nothing. We should fix this by removing that #define entirely, and dealing with the fallout separately which may turn up even more bugs. I fixed this by replacing them with the corresponding LLVM macros which understand how to do these operations on all the different compilers. llvm-svn: 280757
* [llvm-cov] Add the project summary to the text coverage report for each ↵Ying Yi2016-09-067-12/+24
| | | | | | | | | | source file. This patch is a spin-off from https://reviews.llvm.org/D23922. It extends the text view to preserve the same feature as the html view. Differential Revision: https://reviews.llvm.org/D24241 llvm-svn: 280756
* Reorder FreeBSD Host.cpp #includes to fix buildEd Maste2016-09-061-6/+8
| | | | llvm-svn: 280755
* Try 2 - Remove <cstdlib> include from `<exception>`Eric Fiselier2016-09-064-4/+9
| | | | | | | | | | | This patch removes the `<cstdlib>` include from exception where it is no longer needed. Unlike my previous attempt this patch also adds <cstdlib> where needed in other headers like <new> and <typeinfo>. This won't fix the Firefox build issues discussed on IRC but it is more correct for libc++. llvm-svn: 280754
* Fix shared library build.Rafael Espindola2016-09-062-0/+2
| | | | llvm-svn: 280753
* Revert r280743 and r280745. Remove <cstdlib> include from `<exception>`Eric Fiselier2016-09-062-1/+4
| | | | | | | Apparently I missed a number of additional include which need to be added. Reverting so I can recommit as a single patch with all of the required includes. llvm-svn: 280752
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-062780-598021/+557651
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Avoid using alignas and constexpr.Rafael Espindola2016-09-061-136/+5
| | | | | | | This requires removing the custom allocator, since Demangle cannot depend on Support and so cannot use Compiler.h. llvm-svn: 280750
* [AMDGPU] Wave and register controlsKonstantin Zhuravlyov2016-09-061-0/+190
| | | | | | - Add missing test llvm-svn: 280749
* [CMake] Cleanup LLVM_OPTIMIZED_TABLEGENChris Bieneman2016-09-062-14/+21
| | | | | | | | | | This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations. The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad. Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it. llvm-svn: 280748
* [AMDGPU] Wave and register controlsKonstantin Zhuravlyov2016-09-0632-258/+854
| | | | | | | | | | | | | | - Implemented amdgpu-flat-work-group-size attribute - Implemented amdgpu-num-active-waves-per-eu attribute - Implemented amdgpu-num-sgpr attribute - Implemented amdgpu-num-vgpr attribute - Dynamic LDS constraints are in a separate patch Patch by Tom Stellard and Konstantin Zhuravlyov Differential Revision: https://reviews.llvm.org/D21562 llvm-svn: 280747
* Try to fix a circular dependency in the modules build.Rafael Espindola2016-09-062-2/+3
| | | | llvm-svn: 280746
* Add missing <cstdlib> include. Sorry about the bot breakageEric Fiselier2016-09-061-0/+1
| | | | llvm-svn: 280745
* AMDGPU/SI: Teach SIInstrInfo::FoldImmediate() to fold immediates into copiesTom Stellard2016-09-062-3/+29
| | | | | | | | | | | | | | | | | | | | Summary: I put this code here, because I want to re-use it in a few other places. This supersedes some of the immediate folding code we have in SIFoldOperands. I think the peephole optimizers is probably a better place for folding immediates into copies, since it does some register coalescing in the same time. This will also make it easier to transition SIFoldOperands into a smarter pass, where it looks at all uses of instruction at once to determine the optimal way to fold operands. Right now, the pass just considers one operand at a time. Reviewers: arsenm Subscribers: wdng, nhaehnle, arsenm, llvm-commits, kzhuravl Differential Revision: https://reviews.llvm.org/D23402 llvm-svn: 280744
* Remove unneeded includes in <exception> after removing __libcpp_throwEric Fiselier2016-09-061-4/+0
| | | | llvm-svn: 280743
* AMDGPU : Add XNACK feature to GPUs that support it.Wei Ding2016-09-062-3/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D24276 llvm-svn: 280742
* [include-fixer] Fix some Clang-tidy modernize-use-override and Include What ↵Eugene Zelenko2016-09-062-3/+9
| | | | | | | | You Use warnings; other minor fixes. Differential revision: https://reviews.llvm.org/D24179 llvm-svn: 280741
* Fix ItaniumDemangle.cpp build with MSVC 2013Reid Kleckner2016-09-061-18/+19
| | | | llvm-svn: 280740
OpenPOWER on IntegriCloud