summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
* Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; ↵Eugene Zelenko2016-01-261-2/+2
| | | | | | | | other minor fixes. Differential revision: reviews.llvm.org/D16568 llvm-svn: 258831
* [ARM] Add DSP build attribute and extension targetingBradley Smith2016-01-251-0/+1
| | | | | | | | This patch was originally committed as r257885, but was reverted due to windows failures. The cause of these failures has been fixed under r258677, hence re-committing the original patch. llvm-svn: 258683
* Added Skylake client to X86 targets and featuresElena Demikhovsky2016-01-241-3/+12
| | | | | | | | | | | | | Changes in X86.td: I set features of Intel processors in incremental form: IVB = SNB + X HSW = IVB + X .. I added Skylake client processor and defined it's features FeatureADX was missing on KNL Added some new features to appropriate processors SMAP, IFMA, PREFETCHWT1, VMFUNC and others Differential Revision: http://reviews.llvm.org/D16357 llvm-svn: 258659
* AMDGPU: Fix getArchTypePrefixMatt Arsenault2016-01-221-2/+2
| | | | llvm-svn: 258525
* parseArch() supports more variations of arch names for PowerPC buildsKelvin Li2016-01-191-4/+4
| | | | llvm-svn: 258103
* [AVX512] adding AVXVBMI feature flagMichael Zuckerman2016-01-181-1/+1
| | | | | | | | | Fixing wrong typo (avx515) → (avx512) Review over the shoulder by asaf . Differential Revision: http://reviews.llvm.org/D16190 llvm-svn: 258041
* [AVX512] adding AVXVBMI feature flagMichael Zuckerman2016-01-171-0/+1
| | | | | | | | | | The feature flag is for VPERMB,VPERMI2B,VPERMT2B and VPMULTISHIFTQB instructions. More about the instruction can be found in: hattps://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdf Differential Revision: http://reviews.llvm.org/D16190 llvm-svn: 258012
* # This is a combination of 2 commits.Reid Kleckner2016-01-151-1/+0
| | | | | | | | | | | | | | | | # The first commit's message is: Revert "[ARM] Add DSP build attribute and extension targeting" This reverts commit b11cc50c0b4a7c8cdb628abc50b7dc226ff583dc. # This is the 2nd commit message: Revert "[ARM] Add new system registers to ARMv8-M Baseline/Mainline" This reverts commit 837d08454e3e5beb8581951ac26b22fa07df3cd5. llvm-svn: 257916
* [ARM] Add DSP build attribute and extension targetingBradley Smith2016-01-151-0/+1
| | | | llvm-svn: 257885
* [ARM] Add ARMv8-M Baseline/Mainline LLVM targetingBradley Smith2016-01-152-0/+10
| | | | llvm-svn: 257878
* Update to use new name alignTo().Rui Ueyama2016-01-141-1/+1
| | | | llvm-svn: 257804
* Auto-link with ole32.dll to simplify building LLVM.dllReid Kleckner2016-01-121-0/+1
| | | | | | Patch by Jakob Bornecrantz llvm-svn: 257499
* The --debug-only option now takes a comma separated list of debug types.Christof Douma2016-01-121-3/+5
| | | | | | | | | This means that the DEBUG_TYPE cannot take a comma anymore. All existing passes conform to this rule. Differential Revision: http://reviews.llvm.org/D15645 llvm-svn: 257466
* Avoid the deprecated GetVersionEx APIReid Kleckner2016-01-112-10/+19
| | | | | | | | | Apparently the preferred version is the incredibly complicated VerifyVersionInfoW function. Rename the function to avoid potential future name clashes. llvm-svn: 257415
* Revert "[Windows] Simplify assertion code. NFC."Reid Kleckner2016-01-111-1/+4
| | | | | | | | | | | | | This reverts commit r254363. load64BitDebugHelp() has the side effect of loading dbghelp and setting globals. It should be called in no-asserts builds as well as debug builds. llvm_unreachable is also not appropriate here, since we actually want to return if dbghelp couldn't be loaded in a non-asserts build. llvm-svn: 257384
* Use ::GetVersionEx directly rather than the Win8.1 SDK helpersReid Kleckner2016-01-111-6/+4
| | | | | | | | This removes ifdefs and fixes the build for users of the Win8.0 SDK, which I happen to be. Upgrading is not hard, but executing the same code everywhere seems better. llvm-svn: 257379
* IntEqClasses: Let join() return the new leaderMatthias Braun2016-01-081-1/+3
| | | | | | | | The new leader is known anyway so we can return it for some micro optimization in code where it is easy to pass along the result to the next join(). llvm-svn: 257130
* Mark arm as the 32bit variant of aarch64 in TripleTamas Berghammer2016-01-071-28/+28
| | | | | | | | | | Change Triple::get32BitArchVariant to return arm/armeb as the 32bit variant of aarch64/aarch64_be and do the same change for the oppoiste direction in Triple::get64BitArchVariant. Differential revision: http://reviews.llvm.org/D15529 llvm-svn: 257048
* Do not define NOGDI. Mingw defines LOGFONTW type in wingdi.h and the mingwYunzhong Gao2016-01-061-1/+0
| | | | | | version of shlobj.h includes shobjidl.h and the latter uses the LOGFONTW type. llvm-svn: 256904
* Another attempt at fixing the i686-mingw32-RA-on-linux buildbot. I am gettingYunzhong Gao2016-01-061-4/+2
| | | | | | | | confused with what version of mingw is actually installed on the buildbot, and for now I will just assume this is an unknown version which does not ship with VersionHelpers.h. llvm-svn: 256902
* Another attempt at fixing the i686-mingw32-RA-on-linux buildbot.Yunzhong Gao2016-01-061-2/+3
| | | | llvm-svn: 256901
* Hopefully fix a mingw32 buildbot (i686-mingw32-RA-on-linux) which does not haveYunzhong Gao2016-01-061-1/+5
| | | | | | the VersionHelpers.h header. llvm-svn: 256896
* Fixing PR25717: fatal IO error writing large outputs to console on Windows.Yunzhong Gao2016-01-062-1/+34
| | | | | | | | | | | | | This patch is similar to the Python issue#11395. We need to cap the output size to 32767 on Windows to work around the size limit of WriteConsole(). Reference: https://bugs.python.org/issue11395 Writing a test for this bug turns out to be harder than I thought. I am still working on it (see phabricator review D15705). Differential Revision: http://reviews.llvm.org/D15553 llvm-svn: 256892
* [Clang/Support/Windows/Unix] Command lines created by clang may exceed the ↵Oleg Ranevskyy2016-01-052-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | command length limit set by the OS Summary: Hi Rafael, Would you be able to review this patch, please? (Clang part of the patch is D15832). When clang runs an external tool, e.g. a linker, it may create a command line that exceeds the length limit. Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS limitation. There are two problems in this function that may cause exceeding of the limit: 1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program path to the command line when it runs the program. 2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails. Reviewers: rafael, ygao, probinson Subscribers: asl, llvm-commits Differential Revision: http://reviews.llvm.org/D15831 llvm-svn: 256866
* Refactor: Simplify boolean conditional return statements in llvm/lib/SupportAlexander Kornienko2015-12-282-8/+3
| | | | | | | | | | | | | | Summary: Use clang-tidy to simplify boolean conditional return statements Reviewers: rafael, bkramer, ddunbar, Bigcheese, chandlerc, chapuni, nicholas, alexfh Subscribers: alexfh, craig.topper, llvm-commits Patch by Richard Thomson! Differential Revision: http://reviews.llvm.org/D9978 llvm-svn: 256500
* [Support] Allow multiple paired calls to {start,stop}Timer()Vedant Kumar2015-12-221-18/+14
| | | | | | | Differential Revision: http://reviews.llvm.org/D15619 Reviewed-by: rafael llvm-svn: 256258
* [MC] Don't use the architecture to govern which object file format to useDavid Majnemer2015-12-221-11/+37
| | | | | | | | | | | InitMCObjectFileInfo was trying to override the triple in awkward ways. For example, a triple specifying COFF but not Windows was forced as ELF. This makes it easy for internal invariants to get violated, such as those which triggered PR25912. This fixes PR25912. llvm-svn: 256226
* [Support] Timer: Use emplace_back() and range-based loops (NFC)Vedant Kumar2015-12-211-4/+4
| | | | llvm-svn: 256217
* [Support] Timer: simplify the init() methodVedant Kumar2015-12-211-5/+1
| | | | llvm-svn: 256215
* Reorganize the C API headers to improve build times.Eric Christopher2015-12-182-2/+2
| | | | | | | | | Type specific declarations have been moved to Type.h and error handling routines have been moved to ErrorHandling.h. Both are included in Core.h so nothing should change for projects directly including the headers, but transitive dependencies may be affected. llvm-svn: 255965
* [WebAssembly] Experimental ELF writer supportDan Gohman2015-12-171-5/+2
| | | | | | | | | This creates the initial infrastructure for writing ELF output files. It doesn't yet have any implementation for encoding instructions. Differential Revision: http://reviews.llvm.org/D15555 llvm-svn: 255869
* Drop an unnecessary use of writev.Rafael Espindola2015-12-161-16/+2
| | | | | | | | | | | It looks like the code this patch deletes is based on a misunderstanding of what guarantees writev provides. In particular, writev with 1 iovec is not "more atomic" than a write. Testing on OS X shows that both write and writev from multiple processes can be intermixed. llvm-svn: 255837
* Simplify memory management with std::unique_ptr.Rafael Espindola2015-12-162-27/+18
| | | | llvm-svn: 255831
* [SectionMemoryManager] Make better use of virtual memoryKeno Fischer2015-12-161-2/+3
| | | | | | | | | | | | | | | | | Summary: On Windows, the allocation granularity can be significantly larger than a page (64K), so with many small objects, just clearing the FreeMem list rapidly leaks quite a bit of virtual memory space (if not rss). Fix that by only removing those parts of the FreeMem blocks that overlap pages for which we are applying memory permissions, rather than dropping the FreeMem blocks entirely. Reviewers: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15202 llvm-svn: 255760
* [x86] adding PKU feature flagAsaf Badouh2015-12-151-0/+2
| | | | | | | | | the feature flag is essential for RDPKRU and WRPKRU instruction more about the instruction can be found in the SDM rev 56, vol 2 from http://www.intel.com/sdm Differential Revision: http://reviews.llvm.org/D15491 llvm-svn: 255644
* Fix MSVC build with LLVM_ENABLE_THREADS=OFFMehdi Amini2015-12-151-1/+10
| | | | | | | Follow-up to the ThreadPool implementation. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255621
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-152-0/+147
| | | | | | | | | | | | | | | | | | | | | | | | | This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. This is a recommit of r255444 ; trying to workaround a bug in the MSVC 2013 standard library. I think I was hit by: http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable Recommit of r255589, trying to please g++ as well. Differential Revision: http://reviews.llvm.org/D15464 From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8> llvm-svn: 255593
* Revert "Add a C++11 ThreadPool implementation in LLVM"Mehdi Amini2015-12-152-147/+0
| | | | | | | This reverts commit r255589. Breaks g++ From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255591
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-152-0/+147
| | | | | | | | | | | | | | | | | | | | | | | This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. This is a recommit of r255444 ; trying to workaround a bug in the MSVC 2013 standard library. I think I was hit by: http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable Differential Revision: http://reviews.llvm.org/D15464 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255589
* Reordering fields to reduce padding in LLVM. NFCBen Craig2015-12-141-4/+4
| | | | llvm-svn: 255554
* Revert r255444.Nico Weber2015-12-132-144/+0
| | | | | | | | It doesn't build on Windows and broke the Windows LLD and LLDB bots: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/27693/steps/build_Lld/logs/stdio http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc/builds/13468/steps/build/logs/stdio llvm-svn: 255446
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-122-0/+144
| | | | | | | | | | | | | | | | | | This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. Differential Revision: http://reviews.llvm.org/D15464 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255444
* Avoid buffered reads of /dev/urandomRafael Espindola2015-12-111-4/+9
| | | | | | | | | | | | | | I am seeing disappointing clang performance on a large PowerPC64 Linux box. GetRandomNumberSeed() does a buffered read from /dev/urandom to seed its PRNG. As a result we read an entire page even though we only need 4 bytes. With every clang task reading a page worth of /dev/urandom we end up spending a large amount of time stuck on kernel spinlock. Patch by Anton Blanchard! llvm-svn: 255386
* Macro debug info support in LLVM IRAmjad Aboud2015-12-101-0/+10
| | | | | | | | Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
* Revert "raw_ostream: << operator for callables with raw_stream argument"Matthias Braun2015-12-031-4/+0
| | | | | | | | This commit provoked "error C2593: 'operator <<' is ambiguous" on MSVC. This reverts commit r254655. llvm-svn: 254661
* raw_ostream: << operator for callables with raw_stream argumentMatthias Braun2015-12-031-0/+4
| | | | | | | | | | | | | | | | | This allows easier construction of print helpers. Example: Printable PrintLaneMask(unsigned LaneMask) { return Printable([LaneMask](raw_ostream &OS) { OS << format("%08X", LaneMask); }); } // Usage: OS << PrintLaneMask(Mask); Differential Revision: http://reviews.llvm.org/D14348 llvm-svn: 254655
* [ARM] Add ARMv8.2-A to TargetParserOliver Stannard2015-12-012-0/+5
| | | | | | | | | | | | Add ARMv8.2-A to TargetParser, so that it can be used by the clang command-line options and the .arch directive. Most testing of this will be done in clang, checking that the command-line options that this enables work. Differential Revision: http://reviews.llvm.org/D15037 llvm-svn: 254400
* Use array_lengthof instead of manually calculating it. NFCCraig Topper2015-12-011-3/+2
| | | | llvm-svn: 254380
* [Windows] Partially revert r254363 until I can test the right fix.Davide Italiano2015-12-011-2/+6
| | | | | | Reported by: David Blaikie llvm-svn: 254378
* Replace all weight-based interfaces in MBB with probability-based ↵Cong Hou2015-12-011-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interfaces, and update all uses of old interfaces. (This is the second attempt to submit this patch. The first caused two assertion failures and was reverted. See https://llvm.org/bugs/show_bug.cgi?id=25687) The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes (http://reviews.llvm.org/D13908). 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights (http://reviews.llvm.org/D14361). 3. Use new interfaces in all other passes. 4. Remove old interfaces. This patch is 3+4 above. In this patch, MBB won't provide weight-based interfaces any more, which are totally replaced by probability-based ones. The interface addSuccessor() is redesigned so that the default probability is unknown. We allow unknown probabilities but don't allow using it together with known probabilities in successor list. That is to say, we either have a list of successors with all known probabilities, or all unknown probabilities. In the latter case, we assume each successor has 1/N probability where N is the number of successors. An assertion checks if the user is attempting to add a successor with the disallowed mixed use as stated above. This can help us catch many misuses. All uses of weight-based interfaces are now updated to use probability-based ones. Differential revision: http://reviews.llvm.org/D14973 llvm-svn: 254377
OpenPOWER on IntegriCloud