summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [SE] Rename PlatformInterfaces to PlatformDeviceJason Henline2016-09-0611-27/+20
| | | | | | | | | | | | | | Summary: The only interface that we ever plan to have in this file is PlatformDevice, so it makes sense to rename the file to reflect that. Reviewers: jprice Subscribers: parallel_libs-commits Differential Revision: https://reviews.llvm.org/D24269 llvm-svn: 280737
* [AArch64] Adjust the scheduling model for Exynos M1.Evandro Menezes2016-09-061-18/+16
| | | | | | Further refine the model for branches. llvm-svn: 280736
* [AArch64] Adjust the scheduling model for Exynos M1.Evandro Menezes2016-09-061-2/+7
| | | | | | Further refine the model for stores. llvm-svn: 280735
* [AArch64] Adjust the scheduling model for Exynos M1.Evandro Menezes2016-09-061-11/+11
| | | | | | Further refine the model for loads. llvm-svn: 280734
* Use the demangler in llvm.Rafael Espindola2016-09-062-17/+4
| | | | llvm-svn: 280733
* Add an c++ itanium demangler to llvm.Rafael Espindola2016-09-0620-39/+4539
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a copy of the demangler in libcxxabi. The code also has no dependencies on anything else in LLVM. To enforce that I added it as another library. That way a BUILD_SHARED_LIBS will fail if anyone adds an use of StringRef for example. The no llvm dependency combined with the fact that this has to build on linux, OS X and Windows required a few changes to the code. In particular: No constexpr. No alignas On OS X at least this library has only one global symbol: __ZN4llvm16itanium_demangleEPKcPcPmPi My current plan is: Commit something like this Change lld to use it Change lldb to use it as the fallback Add a few #ifdefs so that exactly the same file can be used in libcxxabi to export abi::__cxa_demangle. Once the fast demangler in lldb can handle any names this implementation can be replaced with it and we will have the one true demangler. llvm-svn: 280732
* clang-format: [JS] whitespace required between ! and as.Martin Probst2016-09-062-0/+3
| | | | | | | | | | | | | | | | Summary: Before: x!as string After: x! as string Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D24272 llvm-svn: 280731
* clang-format: [JS] ignore comments when wrapping returns.Martin Probst2016-09-062-1/+8
| | | | | | | | | | | | | | | | | | | Summary: When code contains a comment between `return` and the value: return /* lengthy comment here */ ( lengthyValueComesHere); Do not wrap before the comment, as that'd break the code through JS' automatic semicolon insertion. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D24257 llvm-svn: 280730
* [ELF] Add support for -no-gc-sections flagPetr Hosek2016-09-062-1/+4
| | | | | | | | | This flag is supported by both BFD ld and gold and is occasionally used to negate the effect of -gc-sections flag. Differential Revision: https://reviews.llvm.org/D24270 llvm-svn: 280729
* Modules: Fix an assertion in DeclContext::buildLookup.Manman Ren2016-09-066-4/+28
| | | | | | | | | | When calling getMostRecentDecl, we can pull in more definitions from a module. We call getPrimaryContext afterwards to make sure that we buildLookup on a primary context. rdar://27926200 llvm-svn: 280728
* fix formatting; NFCSanjay Patel2016-09-061-19/+14
| | | | llvm-svn: 280727
* [MCTargetDesc] Delete dead code. Found by GCC7 -Wunused-function.Davide Italiano2016-09-061-17/+0
| | | | | | Also unbreak newer gcc build with -Werror. llvm-svn: 280726
* [Release notes] Fix links.Eugene Zelenko2016-09-061-6/+6
| | | | | | Differential revision: https://reviews.llvm.org/D24201 llvm-svn: 280725
* Add a comment.Rui Ueyama2016-09-061-0/+4
| | | | llvm-svn: 280724
* Fix comment formatting for DebugInfoFlags.defVictor Leschuk2016-09-061-1/+2
| | | | llvm-svn: 280722
* Updated .clang-format rules so bring LLDB in line with LLVM standards.Kate Stone2016-09-062-8/+4
| | | | llvm-svn: 280721
* bugpoint: Return Errors instead of passing around stringsJustin Bogner2016-09-0610-543/+558
| | | | | | | | | | | | | This replaces the threading of `std::string &Error` through all of these APIs with checked Error returns instead. There are very few places here that actually emit any errors right now, but threading the APIs through will allow us to replace a bunch of exit(1)'s that are scattered through this code with proper error handling. This is more or less NFC, but does move around where a couple of error messages are printed out. llvm-svn: 280720
* [SE] Remove Platform*Handle classesJason Henline2016-09-0610-95/+142
| | | | | | | | | | | | | | | | Summary: As pointed out by jprice, these classes don't serve a purpose. Instead, we stay consistent with the way memory is managed and let the Stream and Kernel classes directly hold opaque handles to device Stream and Kernel instances, respectively. Reviewers: jprice, jlebar Subscribers: parallel_libs-commits Differential Revision: https://reviews.llvm.org/D24213 llvm-svn: 280719
* Formatting with clang-format patch r280701Leny Kholodov2016-09-061-23/+24
| | | | llvm-svn: 280718
* [RDF] Ignore undef use operandsKrzysztof Parzyszek2016-09-062-1/+56
| | | | llvm-svn: 280717
* Formatting with clang-format patch r280700Leny Kholodov2016-09-0611-160/+147
| | | | llvm-svn: 280716
* [SelectionDAG] Simplify extract_subvector( insert_subvector ( Vec, In, Idx ↵Simon Pilgrim2016-09-062-9/+10
| | | | | | | | | | | | ), Idx ) -> In If we are extracting a subvector that has just been inserted then we should just use the original inserted subvector. This has come up in certain several x86 shuffle lowering cases where we are crossing 128-bit lanes. Differential Revision: https://reviews.llvm.org/D24254 llvm-svn: 280715
* Add #include <cstdio> to unbreak build (missing definition of stderr)Krzysztof Parzyszek2016-09-061-0/+1
| | | | llvm-svn: 280714
* [JumpThreading] Only write back branch-weight MDs for blocks that originally ↵Adam Nemet2016-09-063-1/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | had PGO info Currently the pass updates branch weights in the IR if the function has any PGO info (entry frequency is set). However we could still have regions of the CFG that does not have branch weights collected (e.g. a cold region). In this case we'd use static estimates. Since static estimates for branches are determined independently, they are inconsistent. Updating them can "randomly" inflate block frequencies. I've run into this in a completely cold loop of h264ref from SPEC. -Rpass-with-hotness showed the loop to be completely cold during inlining (before JT) but completely hot during vectorization (after JT). The new testcase demonstrate the problem. We check array elements against 1, 2 and 3 in a loop. The check against 3 is the loop-exiting check. The block names should be self-explanatory. In this example, jump threading incorrectly updates the weight of the loop-exiting branch to 0, drastically inflating the frequency of the loop (in the range of billions). There is no run-time profile info for edges inside the loop, so branch probabilities are estimated. These are the resulting branch and block frequencies for the loop body: check_1 (16) (8) / | eq_1 | (8) \ | check_2 (16) (8) / | eq_2 | (8) \ | check_3 (16) (1) / | (loop exit) | (15) | (back edge) First we thread eq_1 -> check_2 to check_3. Frequencies are updated to remove the frequency of eq_1 from check_2 and then from the false edge leaving check_2. Changed frequencies are highlighted with * *: check_1 (16) (8) / | eq_1~ | (8) / | / check_2 (*8*) / (8) / | \ eq_2 | (*0*) \ \ | ` --- check_3 (16) (1) / | (loop exit) | (15) | (back edge) Next we thread eq_1 -> check_3 and eq_2 -> check_3 to check_1 as new back edges. Frequencies are updated to remove the frequency of eq_1 and eq_3 from check_3 and then the false edge leaving check_3 (changed frequencies are highlighted with * *): check_1 (16) (8) / | eq_1~ | (8) / | / check_2 (*8*) / (8) / | /-- eq_2~ | (*0*) (back edge) | check_3 (*0*) (*0*) / | (loop exit) | (*0*) | (back edge) As a result, the loop exit edge ends up with 0 frequency which in turn makes the loop header to have maximum frequency. There are a few potential problems here: 1. The profile data seems odd. There is a single profile sample of the loop being entered. On the other hand, there are no weights inside the loop. 2. Based on static estimation we shouldn't set edges to "extreme" values, i.e. extremely likely or unlikely. 3. We shouldn't create profile metadata that is calculated from static estimation. I am not sure what policy is but it seems to make sense to treat profile metadata as something that is known to originate from profiling. Estimated probabilities should only be reflected in BPI/BFI. Any one of these would probably fix the immediate problem. I went for 3 because I think it's a good policy to have and added a FIXME about 2. Differential Revision: https://reviews.llvm.org/D24118 llvm-svn: 280713
* Fix for Bindings/Go/go.test after patch r280700Leny Kholodov2016-09-061-6/+10
| | | | llvm-svn: 280711
* [Sparc][Leon] Corrected supported atomics size for processors supporting ↵Chris Dewhurst2016-09-061-1/+1
| | | | | | | | Leon CASA instruction back to 32 bits. This was erroneously checked-in for 64 bits while trying to find if there was a way to get 64 bit atomicity in Leon processors. There is not and this change should not have been checked-in. There is no unit test for this as the existing unit tests test for behaviour to 32 bits, which was the original intention of the code. llvm-svn: 280710
* Mark R_GOTREL_FROM_END as a relative expression.Rafael Espindola2016-09-062-2/+26
| | | | | | Fixes pr30282. llvm-svn: 280709
* [ELF] - Linkerscript: implemented FILL command as alias for =fillexprGeorge Rimar2016-09-063-9/+47
| | | | | | | | | Patch implements FILL just as alias for =fillexpr. This allows to make implementation much shorted and simpler than D24186. Differential revision: https://reviews.llvm.org/D24227 llvm-svn: 280708
* Fixing an MSVC error from rL280692Dimitar Vlahovski2016-09-061-1/+1
| | | | | | | | | MSVC emits an error when one uses a const variable in a lambda without capturing it. gcc and clang don't emit an error in this scenario. llvm-svn: 280707
* [mips] Tighten FastISel restrictionsSimon Dardis2016-09-062-1/+31
| | | | | | | | | | | | | | | | | | LLVM PR/29052 highlighted that FastISel for MIPS attempted to lower arguments assuming that it was using the paired 32bit registers to perform operations for f64. This mode of operation is not supported for MIPSR6. This patch resolves the reported issue by adding additional checks for unsupported floating point unit configuration. Thanks to mike.k for reporting this issue! Reviewers: seanbruno, vkalintiris Differential Review: https://reviews.llvm.org/D23795 llvm-svn: 280706
* [PPC] Claim stack frame before storing into it, if no red zone is presentKrzysztof Parzyszek2016-09-066-46/+120
| | | | | | | | | | | | | Unlike PPC64, PPC32/SVRV4 does not have red zone. In the absence of it there is no guarantee that this part of the stack will not be modified by any interrupt. To avoid this, make sure to claim the stack frame first before storing into it. This fixes https://llvm.org/bugs/show_bug.cgi?id=26519. Differential Revision: https://reviews.llvm.org/D24093 llvm-svn: 280705
* Second round of fixups for r280692Pavel Labath2016-09-062-4/+5
| | | | | | | Android targets don't have std::to_string and std::stoul. Use llvm::to_string and strtoul instead. llvm-svn: 280704
* Revert "Intel(R) Memory Protection Extensions (Intel(R) MPX) support."Dimitar Vlahovski2016-09-0617-501/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit rL280668 because the register tests fail on i386 Linux. I investigated a little bit what causes the failure - there are missing registers when running 'register read -a'. This is the output I got at the bottom: """ ... Memory Protection Extensions: bnd0 = {0x0000000000000000 0x0000000000000000} bnd1 = {0x0000000000000000 0x0000000000000000} bnd2 = {0x0000000000000000 0x0000000000000000} bnd3 = {0x0000000000000000 0x0000000000000000} unknown: 2 registers were unavailable. """ Also looking at the packets exchanged between the client and server: """ ... history[308] tid=0x7338 < 19> send packet: $qRegisterInfo4a#d7 history[309] tid=0x7338 < 130> read packet: $name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:101;dwarf:101;#48 history[310] tid=0x7338 < 19> send packet: $qRegisterInfo4b#d8 history[311] tid=0x7338 < 130> read packet: $name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:102;dwarf:102;#52 history[312] tid=0x7338 < 19> send packet: $qRegisterInfo4c#d9 history[313] tid=0x7338 < 130> read packet: $name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:103;dwarf:103;#53 history[314] tid=0x7338 < 19> send packet: $qRegisterInfo4d#da history[315] tid=0x7338 < 130> read packet: $name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:104;dwarf:104;#54 history[316] tid=0x7338 < 19> send packet: $qRegisterInfo4e#db history[317] tid=0x7338 < 76> read packet: $name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99 history[318] tid=0x7338 < 19> send packet: $qRegisterInfo4f#dc history[319] tid=0x7338 < 78> read packet: $name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e ... """ The bndcfgu and bndstatus registers don't have the 'Memory Protections Extension' set. I looked at the code and it seems that that is set correctly. So I'm not sure what's the problem or where does it come from. Also there is a second failure related to something like this in the tests: """ registerSet.GetName().lower() """ For some reason the registerSet.GetName() returns None. llvm-svn: 280703
* [clang-cl] Check that we are in clang cl mode before enabling support for ↵Pierre Gousseau2016-09-062-1/+3
| | | | | | | | | | the CL environment variable. Checking for the type of the command line tokenizer should not be the criteria to enable support for the CL environment variable, this change checks that we are in clang-cl mode instead. Differential Revision: https://reviews.llvm.org/D23503 llvm-svn: 280702
* DebugInfo: use llvm::DINode::DIFlags type for debug info flagsLeny Kholodov2016-09-062-34/+40
| | | | | | | | | | Use llvm::DINode::DIFlags type (strongly typed enum) for debug flags instead of unsigned int to avoid problems on platforms with sizeof(int) < 4: we already have flags with values > (1 << 16). Patch by: Victor Leschuk <vleschuk@gmail.com> Differential Revision: https://reviews.llvm.org/D23767 llvm-svn: 280701
* DebugInfo: use strongly typed enum for debug info flagsLeny Kholodov2016-09-0613-205/+233
| | | | | | | | | | | | Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes: Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4 Flags are now strongly typed Patch by: Victor Leschuk <vleschuk@gmail.com> Differential Revision: https://reviews.llvm.org/D23766 llvm-svn: 280700
* [OpenCL] Remove access qualifiers on images in arg info metadata.Alexey Bader2016-09-062-12/+41
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Remove access qualifiers on images in arg info metadata: * kernel_arg_type * kernel_arg_base_type Image access qualifiers are inseparable from type in clang implementation, but OpenCL spec provides a special query to get access qualifier via clGetKernelArgInfo with CL_KERNEL_ARG_ACCESS_QUALIFIER. Besides that OpenCL conformance test_api get_kernel_arg_info expects image types without access qualifier. Patch by Evgeniy Tyurin. Reviewers: bader, yaxunl, Anastasia Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23915 llvm-svn: 280699
* [RegisterScavenger] Remove aliasing registers of operands from the candidate setSilviu Baranga2016-09-061-1/+2
| | | | | | | | | | | | | | | | | | | | Summary: In addition to not including the register operand of the current instruction also don't include any aliasing registers. We can't consider these as candidates because using them will clobber the corresponding register operand of the current instruction. This change doesn't include a test case and it would probably be difficult to produce a stable one since the bug depends on the results of register allocation. Reviewers: MatzeB, qcolombet, hfinkel Subscribers: hfinkel, llvm-commits Differential Revision: https://reviews.llvm.org/D24130 llvm-svn: 280698
* Fix build breakage in r280692Pavel Labath2016-09-063-3/+3
| | | | | | | | | The commit introduced an array of const objects, which libstdc++ does not like. Make the object non-const. Also fix a compiler warning while I'm in there. llvm-svn: 280697
* [AVX-512] Fix masked VPERMI2PS isel when the index comes from a bitcast.Craig Topper2016-09-064-61/+41
| | | | | | We need to bitcast the index operand to a floating point type so that it matches the result type. If not then the passthru part of the DAG will be a bitcast from the index's original type to the destination type. This makes it very difficult to match. The other option would be to add 5 sets of patterns for every other possible type. llvm-svn: 280696
* [AVX-512] Add a test case to show that we don't select masked vpermi2ps when ↵Craig Topper2016-09-061-4/+17
| | | | | | | | | | the index operand comes from a bitcast. It doesn't work because we're looking for a bitcast from the v4i32 index operand to v4f32 for the passthru part of the DAG. But since the index is bitcasted from v2i64 and bitcasts fold, we actually have a bitcast from v2i64 to v4f32 in the passthru part of the DAG. Taken from optimized output from clang's test case. llvm-svn: 280695
* [X86] Remove unused encoding from IntrinsicType enum.Craig Topper2016-09-062-4/+1
| | | | llvm-svn: 280694
* [X86] Fix indentation. NFCCraig Topper2016-09-061-2/+2
| | | | llvm-svn: 280693
* Added the "frame diagnose" command and use its output to make crash info better.Sean Callanan2016-09-0643-4/+2154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
* Revert "bugpoint: Stop threading errors through APIs that never fail"Justin Bogner2016-09-067-90/+112
| | | | | | | | | | | | | This isn't the right thing to do - it turns out a number of the APIs that "never fail" just exit(1) if something bad happens. We can and should thread Error through this instead. That diff will make more sense with this reverted. Sorry for the noise. This reverts r280690 llvm-svn: 280691
* bugpoint: Stop threading errors through APIs that never failJustin Bogner2016-09-067-112/+90
| | | | | | | | | | | | | This simplifies ListReducer and most of its subclasses by removing the std::string &Error that was threaded through all of them but almost never used. If we end up needing error handling in more places here we can reinstate it using llvm::Error instead of these unwieldy strings. The 2 cases (out of 12) that actually can hit the error cases are a little bit awkward now, but those will clean up as I refactor this API further. llvm-svn: 280690
* ARM: workaround bundled operation predicationSaleem Abdulrasool2016-09-062-0/+27
| | | | | | | | | | | | | | | | | | | | | | This is a Windows ARM specific issue. If the code path in the if conversion ends up using a relocation which will form a IMAGE_REL_ARM_MOV32T, we end up with a bundle to ensure that the mov.w/mov.t pair is not split up. This is normally fine, however, if the branch is also predicated, then we end up trying to predicate the bundle. For now, report a bundle as being unpredicatable. Although this is false, this would trigger a failure case previously anyways, so this is no worse. That is, there should not be any code which would previously have been if converted and predicated which would not be now. Under certain circumstances, it may be possible to "predicate the bundle". This would require scanning all bundle instructions, and ensure that the bundle contains only predicatable instructions, and converting the bundle into an IT block sequence. If the bundle is larger than the maximal IT block length (4 instructions), it would require materializing multiple IT blocks from the single bundle. llvm-svn: 280689
* Revert "DebugInfo: use strongly typed enum for debug info flags"Mehdi Amini2016-09-0613-309/+292
| | | | | | This reverts commit r280686, bots are broken. llvm-svn: 280688
* [LTO] Constify (NFC)Mehdi Amini2016-09-061-16/+20
| | | | llvm-svn: 280687
* DebugInfo: use strongly typed enum for debug info flagsMehdi Amini2016-09-0613-292/+309
| | | | | | | | | | | | Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes: * Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4 * Flags are now strongly typed Patch by: Victor Leschuk <vleschuk@gmail.com> Differential Revision: https://reviews.llvm.org/D23766 llvm-svn: 280686
OpenPOWER on IntegriCloud