summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* Allow demangler's node allocator to fail, and bail out of the entireRichard Smith2018-08-241-5/+21
| | | | | | | | | | | | | | | | demangling process when it does. Use this to support a "lookup" query for the mangling canonicalizer that does not create new nodes. This could also be used to implement demangling with a fixed-size temporary storage buffer. Reviewers: erik.pilkington Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51003 llvm-svn: 340670
* Add data structure to form equivalence classes of mangled names.Richard Smith2018-08-242-0/+308
| | | | | | | | | | | | | | | Summary: Given a set of equivalent name fragments, this mechanism determines whether two mangled names are equivalent. The intent is to use this for fuzzy matching of profile data against the program after certain refactorings are performed. Reviewers: erik.pilkington, dlj Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D50935 llvm-svn: 340663
* [Support] Allow discarding a FileOutputBuffer without removing the memory ↵Martin Storsjo2018-08-241-0/+6
| | | | | | | | mapping Differential Revision: https://reviews.llvm.org/D51095 llvm-svn: 340634
* Make LLVM_ENABLE_CRASH_DUMPS set a variable defaultReid Kleckner2018-08-231-5/+4
| | | | | | | That way users can set the default to true, but then disable core dumps from certain apps that link support. llvm-svn: 340588
* Fixup AreCoreFilesPrevented() to consider first LLVM_ENABLE_CRASH_DUMPS and ↵Douglas Yung2018-08-231-1/+1
| | | | | | | | | secondly coreFilesPrevented. The previous change ignored the latter resulting in crash dumps being generated when LLVM_ENABLE_CRASH_DUMPS was set, but coreFilesPrevented was true. llvm-svn: 340561
* [Support] Fix some Wundef warningsSven van Haastregt2018-08-234-10/+10
| | | | | | | | | | For the _WIN32 macro, it is the definedness that matters rather than the value. Most uses of the macro already rely on the definedness. This commit fixes the few remaining uses that relied on the value. Differential Revision: https://reviews.llvm.org/D51105 llvm-svn: 340520
* Improve incompatible triple errorJF Bastien2018-08-231-1/+1
| | | | | | When complaining that the triple is incompatible with all targets, print out the triple not just a generic error about triples not matching. llvm-svn: 340509
* [Support][CachePruning] prune least recently accessed files firstBob Haarman2018-08-221-12/+35
| | | | | | | | | | | | | | | | | Summary: Before this change, pruning order was based on size. This changes it to be based on time of last use instead, preferring to keep recently used files and prune older ones. Reviewers: pcc, rnk, espindola Reviewed By: rnk Subscribers: emaste, arichardson, hiraditya, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51062 llvm-svn: 340374
* Try to fix bot build failureMatt Arsenault2018-08-211-1/+1
| | | | llvm-svn: 340296
* AMDGPU: Partially move target handling code from clang to TargetParserMatt Arsenault2018-08-211-0/+147
| | | | | | | | | | | | | | | | | | | | A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
* Add cmake option to disable minidumps, default it to offReid Kleckner2018-08-201-1/+2
| | | | | | | | | | | | | Since crash dumping landed in r268519, May 2016, I have not once seen anyone use an uploaded minidump to debug a compiler crash. Therefore, I'm turning this off by default. The dumps clutter up user and buildbot temp directories. Each file is only about 56KB, but it adds up. In the context of clang, the extra line about the minidump confuses users, when what we really want from them is the pre-processed source code. llvm-svn: 340185
* Fix an undefined behavior when storing an empty StringRef.Haojian Wu2018-08-201-1/+2
| | | | | | | | | | | | Summary: Passing a nullptr to memcpy is UB. Reviewers: ioeric Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D50966 llvm-svn: 340170
* [DebugCounters] don't do redundant map lookups; NFCGeorge Burgess IV2018-08-171-4/+8
| | | | llvm-svn: 340104
* [ARM/AArch64] Support FP16 +fp16fml instructionsBernard Ogden2018-08-171-0/+7
| | | | | | | | | | | | | | | | | | Add +fp16fml feature for new FP16 instructions, which are a mandatory part of FP16 from v8.4-A and an optional part of FP16 from v8.2-A. It doesn't seem to be possible to model this in LLVM, but the relationship between the options is handled by the related clang patch. In keeping with what I think is the usual practice, the fp16fml extension is accepted regardless of base architecture version. Builds on/replaces Sjoerd Meijer's patch to add these instructions at https://reviews.llvm.org/D49839. Differential Revision: https://reviews.llvm.org/D50228 llvm-svn: 340013
* [Support] Add a public API to allow clearing all (static) timer groups.Graydon Hoare2018-08-171-2/+13
| | | | | | | | | | | | | | | | | | | | | | Summary: Formerly, all timer groups were automatically cleared when printed out. In https://reviews.llvm.org/rL324788 this behaviour was changed to not-clearing timers on printout, to allow printing timers more than once, but as a result clients (specifically Swift) that relied on the clear-on-print behaviour to inhibit duplicate timer printing on shutdown were broken. Rather than revert that change, this change adds a new API that enables clients that _want_ to clear all timers to do so explicitly. Reviewers: george.karpenkov, thegameg Reviewed By: george.karpenkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50874 llvm-svn: 339980
* [ADT] Replace APInt::WORD_MAX with APInt::WORDTYPE_MAXSimon Pilgrim2018-08-161-9/+9
| | | | | | | | | | | | The windows SDK defines WORD_MAX, so any poor soul that wants to use LLVM in a project that depends on the windows SDK gets a build error. Given that it actually describes the maximal value of WordType, it actually fits even better than WORD_MAX Patch by: @miscco Differential Revision: https://reviews.llvm.org/D50777 llvm-svn: 339863
* [Support] Add a basic C API for llvm::Error.Lang Hames2018-08-151-0/+20
| | | | | | | | | | | | | | | | Summary: The C-API supports consuming errors, converting an error to a string error message, and querying an error's type. Other LLVM C APIs that wish to use llvm::Error can supply error-type-id checkers and custom error-to-structured-type converters for any custom errors they provide. Reviewers: bogner, zturner, labath, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50716 llvm-svn: 339802
* [Support] NFC: Allow modifying access/modification times independently in ↵Jordan Rupprecht2018-08-132-7/+14
| | | | | | | | | | | | | | | | | sys::fs::setLastModificationAndAccessTime. Summary: Add an overload to sys::fs::setLastModificationAndAccessTime that allows setting last access and modification times separately. This will allow tools to use this API when they want to preserve both the access and modification times from an input file, which may be different. Also note that both the POSIX (futimens/futimes) and Windows (SetFileTime) APIs take the two timestamps in the order of (1) access (2) modification time, so this renames the method to "setLastAccessAndModificationTime" to make it clear which timestamp is which. For existing callers, the 1-arg overload just sets both timestamps to the same thing. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50521 llvm-svn: 339628
* [ADT] Normalize empty triple componentsPetr Hosek2018-08-081-0/+6
| | | | | | | | | | | | | | | | | LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
* Refactor FileCheck to make it usable as an APIAditya Nandakumar2018-08-072-0/+1341
| | | | | | | | | | https://reviews.llvm.org/D50283 reviewed by bogner This patch refactors FileCheck's implementation into support so it can be used from C++ in other places (Unit tests). llvm-svn: 339192
* Fix raw_fd_ostream::write_impl hang due to an infinite loop with large outputOwen Reynolds2018-08-061-4/+4
| | | | | | | | | | On windows when raw_fd_ostream::write_impl calls write, a 32 bit input is required for character count. As a variable with size_t is used for this argument, on x64 integral demotion occurs. In the case of large files an infinite loop follows. See: https://bugs.llvm.org/show_bug.cgi?id=37926 This fix allows the output of files larger than the previous int32 limit. Differential Revision: https://reviews.llvm.org/D48948 llvm-svn: 339027
* Fix modules build with different technique to suppress Knuth debuggingTim Northover2018-08-061-37/+33
| | | | | | | | | | Currently we use #pragma push_macro(LLVM_DEBUG) to fiddle with the LLVM_DEBUG macro so that we can silence debugging the Knuth division algorithm unless it's actually desired. Unfortunately this is incompatible with enabling modules while building LLVM (via LLVM_ENABLE_MODULES=ON), probably due to a bug being fixed by D33004. llvm-svn: 339009
* Fix buildbot breakage.Rui Ueyama2018-08-041-2/+1
| | | | llvm-svn: 338940
* Use the same constants as zlib to represent compression level.Rui Ueyama2018-08-041-17/+4
| | | | | | | | | | This change allows users pass compression level that was not listed in the enum. Also, I think using different values than zlib's compression levels was just confusing. Differential Revision: https://reviews.llvm.org/D50196 llvm-svn: 338939
* [Support] Don't initialize compressed buffer allocated by zlib::compressFangrui Song2018-08-031-2/+2
| | | | | | | | | | | resize() (zeroing) makes every allocated page resident. The actual size of the compressed buffer is usually much smaller. Making every page resident is wasteful. When linking a test binary with ~1.9GiB uncompressed debug info with LLD, this optimization decreases max RSS by ~1.5GiB. Differential Revision: https://reviews.llvm.org/50223 llvm-svn: 338913
* [Windows FS] Allow moving files in TempFile::keepJeremy Morse2018-08-032-2/+10
| | | | | | | | | | | | In r338216 / D49860 TempFile::keep was extended to allow keeping across filesystems. The aim on Windows was to have this happen in rename_internal using the existing system API. However, to fix an issue and preserve the idea of "renaming" not being a move, put Windows keep-across-filesystem in TempFile::keep. Differential Revision: https://reviews.llvm.org/D50048 llvm-svn: 338841
* [Support] Add an enable bit to our DebugCountersGeorge Burgess IV2018-08-021-0/+2
| | | | | | | | | | | | | | | | | r337748 made us start incrementing DebugCounters all of the time. This makes tsan unhappy in multithreaded environments. Since it doesn't make much sense to use DebugCounters with multiple threads, this patch makes us only count anything if the user passed a -debug-counter option or if some other piece of code explicitly asks for it (e.g. the pass in D50031). The amount of global state here makes writing a unittest for this behavior somewhat awkward. So, no test is provided. Differential Revision: https://reviews.llvm.org/D50150 llvm-svn: 338762
* Unbreak build after r338758: specify lambda return type explicitlyKrzysztof Parzyszek2018-08-021-1/+1
| | | | llvm-svn: 338760
* [SCEV] Properly solve quadratic equationsKrzysztof Parzyszek2018-08-021-0/+191
| | | | | | Differential Revision: https://reviews.llvm.org/D48283 llvm-svn: 338758
* [Support] [NFC] change comment about retries in createUniqueEntityBob Haarman2018-08-021-2/+4
| | | | | | Rewording as requested on D50126 after the change was pushed. llvm-svn: 338755
* [Support] fix TempFile infinite loop and permission denied errorsBob Haarman2018-08-021-35/+42
| | | | | | | | | | | | | | | | | | | | Summary: On Windows, TempFile::create() was prone to failing with permission denied errors when a process created many tempfiles without providing a model large enough to accommodate them. There was also a problem with createUniqueEntity getting into an infinite loop when all names permitted by the model are in use. This change fixes both of these problems and adds a unit test for them. Reviewers: pcc, rnk, zturner Reviewed By: zturner Subscribers: inglorion, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50126 llvm-svn: 338745
* Make ICF log output order deterministic.Rui Ueyama2018-07-311-0/+4
| | | | | | | | | | This patch does the same thing as r338153 for COFF. Note that this patch affects only the order of log messages. The output file is already deterministic. Differential Revision: https://reviews.llvm.org/D50023 llvm-svn: 338406
* Remove trailing spaceFangrui Song2018-07-3016-74/+74
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [dsymutil] Simplify temporary file handling.Jonas Devlieghere2018-07-292-4/+8
| | | | | | | | | | | Dsymutil's update functionality was broken on Windows because we tried to rename a file while we're holding open handles to that file. TempFile provides a solution for this through its keep(Twine) method. This patch changes dsymutil to make use of that functionality. Differential revision: https://reviews.llvm.org/D49860 llvm-svn: 338216
* [Support] Remove unnecessary MemoryBuffer::anchor (where the destructor ↵Fangrui Song2018-07-271-2/+1
| | | | | | serves as the key function) llvm-svn: 338175
* [Support] Use unsigned char for xxHash 64-bitFangrui Song2018-07-271-3/+3
| | | | | | Before, the last 3 bytes were char-signedness dependent. llvm-svn: 338128
* Revert r338027 to pacify build botJames Henderson2018-07-261-4/+4
| | | | llvm-svn: 338035
* [ADT] Replace std::isprint by llvm::isPrint.Michael Kruse2018-07-263-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The standard library functions ::isprint/std::isprint have platform- and locale-dependent behavior which makes LLVM's output less predictable. In particular, regression tests my fail depending on the implementation of these functions. Implement llvm::isPrint in StringExtras.h with a standard behavior and replace all uses of ::isprint/std::isprint by a call it llvm::isPrint. The function is inlined and does not look up language settings so it should perform better than the standard library's version. Such a replacement has already been done for isdigit, isalpha, isxdigit in r314883. gtest does the same in gtest-printers.cc using the following justification: // Returns true if c is a printable ASCII character. We test the // value of c directly instead of calling isprint(), which is buggy on // Windows Mobile. inline bool IsPrintableAscii(wchar_t c) { return 0x20 <= c && c <= 0x7E; } Similar issues have also been encountered by Julia: https://github.com/JuliaLang/julia/issues/7416 I noticed the problem myself when on Windows isprint('\t') started to evaluate to true (see https://stackoverflow.com/questions/51435249) and thus caused several unit tests to fail. The result of isprint doesn't seem to be well-defined even for ASCII characters. Therefore I suggest to replace isprint by a platform-independent version. Differential Revision: https://reviews.llvm.org/D49680 llvm-svn: 338034
* Fix raw_fd_ostream::write_impl hang with large outputJames Henderson2018-07-261-4/+4
| | | | | | | | | | | | | | | | | | | On Windows when raw_fd_ostream::write_impl calls write, a 32 bit input is required for character count. As a variable with size_t is used for this argument on x64 integral demotion occurs. In the case of large files an infinite loop follows. See PR37926. This fix allows the output of files larger than previous int32 limit. Differential Revision: https://reviews.llvm.org/D48948 Patch by Owen Reynolds Reviewed by: zturner llvm-svn: 338027
* [AArch64] Armv8.2-A: add the crypto extensionsSjoerd Meijer2018-07-261-0/+11
| | | | | | | | | This adds MC support for the crypto instructions that were made optional extensions in Armv8.2-A (AArch64 only). Differential Revision: https://reviews.llvm.org/D49370 llvm-svn: 338010
* [Support] Introduce createStringError helper functionVictor Leschuk2018-07-261-0/+4
| | | | | | | | | | | The function in question is copy-pasted lots of times in DWARF-related classes. Thus it will make sense to place its implementation into the Support library. Reviewed by: lhames Differential Revision: https://reviews.llvm.org/D49824 llvm-svn: 337995
* ADT: Shrink SmallVector size 0 to 16B on 64-bit platformsDuncan P. N. Exon Smith2018-07-241-2/+21
| | | | | | | | | | | | | | | | | | | | | SmallVectorTemplateCommon wants to know the address of the first element so it can detect whether it's in "small size" mode. The old implementation split the small array, creating the storage for the first element in SmallVectorTemplateCommon, and pulling the rest into SmallVectorStorage where we know the size of the array. This bloats SmallVector size 0 by the larger of sizeof(void*) and sizeof(T), and we're not even using the storage. The new implementation leaves the full small storage to SmallVectorStorage. To calculate the offset of the first element in SmallVectorTemplateCommon, we just need to know how far to jump, which we can calculate out-of-band. One subtlety is that we need SmallVectorStorage to be properly aligned even when the size is 0, to be sure that (for large alignments) we actually have the padding and it's well defined to do the pointer math. llvm-svn: 337820
* [DebugCounters] Keep track of total countsGeorge Burgess IV2018-07-231-10/+9
| | | | | | | | | | | | | | This patch makes debug counters keep track of the total number of times we've called `shouldExecute` for each counter, so it's easier to build automated tooling on top of these. A patch to print these counts is coming soon. Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D49560 llvm-svn: 337748
* [Support] Add a UniqueStringSaver: like StringSaver, but deduplicating.Sam McCall2018-07-231-0/+7
| | | | | | | | | | | | Summary: Clarify contract of StringSaver (it null-terminates, callers rely on it). Reviewers: hokein Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49596 llvm-svn: 337677
* Reapply "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"Duncan P. N. Exon Smith2018-07-201-11/+14
| | | | | | | | | | | | | | | | | | | | | | I'm optimistically reverting commit r337511, effectively reapplying r337504 *without* changes. The failing bots that had `SmallVector` in the backtrace recovered after the unrelated commit r337508. The backtraces looked bogus anyway, with `SmallVector::size()` calling (e.g.) `ConstantArray::get()`. Here's the original commit message: ADT: Shrink size of SmallVector by 8B on 64-bit platforms Represent size and capacity directly as unsigned and calculate `end()` using `begin() + size()`. This limits the maximum size/capacity of a vector to UINT32_MAX. https://reviews.llvm.org/D48518 llvm-svn: 337514
* Revert "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"Duncan P. N. Exon Smith2018-07-201-14/+11
| | | | | | | | | | | | | | | | | | This reverts commit r337504 while I investigate a TSan bot failure that seems related: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/26526 #8 0x000055581f2895d8 (/b/sanitizer-x86_64-linux-autoconf/build/tsan_debug_build/bin/clang-7+0x1eb45d8) #9 0x000055581f294323 llvm::ConstantAggrKeyType<llvm::ConstantArray>::create(llvm::ArrayType*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:409:0 #10 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::create(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>, std::pair<unsigned int, std::pair<llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray> > >&) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:635:0 #11 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::getOrCreate(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:654:0 #12 0x000055581f2944cb llvm::ConstantArray::get(llvm::ArrayType*, llvm::ArrayRef<llvm::Constant*>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/Constants.cpp:964:0 #13 0x000055581fa27e19 llvm::SmallVectorBase::size() const /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:53:0 #14 0x000055581fa27e19 llvm::SmallVectorImpl<llvm::Constant*>::resize(unsigned long) /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:347:0 #15 0x000055581fa27e19 (anonymous namespace)::EmitArrayConstant(clang::CodeGen::CodeGenModule&, clang::ConstantArrayType const*, llvm::Type*, unsigned int, llvm::SmallVectorImpl<llvm::Constant*>&, llvm::Constant*) /b/sanitizer-x86_64-linux-autoconf/build/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp:669:0 llvm-svn: 337511
* ADT: Shrink size of SmallVector by 8B on 64-bit platformsDuncan P. N. Exon Smith2018-07-191-11/+14
| | | | | | | | | | | Representing size and capacity directly as unsigned and calculate `end()` using `begin() + size()`. This limits the maximum size/capacity of a vector to UINT32_MAX. https://reviews.llvm.org/D48518 llvm-svn: 337504
* [APInt] Keep the original bit width in quotient and remainderKrzysztof Parzyszek2018-07-191-16/+17
| | | | | | | | | | | Some trivial cases in udivrem were handled by directly assigning 0 or 1 to APInt objects. This would set the bit width to 1, instead of the bit width of the inputs. A potentially undesirable side effect of that is that with the bit width of 1, 1 equals -1. Differential Revision: https://reviews.llvm.org/D49554 llvm-svn: 337478
* [Support] Build fix for Haiku when checking for a local filesystemTim Northover2018-07-181-0/+3
| | | | | | | | | Haiku does not expose information about local versus remote mounts, so just return false, like Cygwin. Patch by Niels Sascha Reedijk. llvm-svn: 337389
* Don't assert that a size_t fits into 64bit.Joerg Sonnenberger2018-07-171-1/+0
| | | | | | Avoids tautological compare warnings on 32bit platforms. llvm-svn: 337269
OpenPOWER on IntegriCloud