summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLD][ELF] Support --[no-]mmap-output-file with F_no_mmapNick Terrell2019-10-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add a flag `F_no_mmap` to `FileOutputBuffer` to support `--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores this flag for compatibility with GNU ld and gold. We need this flag to speed up link time for large binaries in certain scenarios. When we link some of our larger binaries we find that LLD takes 50+ GB of memory, which causes memory pressure. The memory pressure causes the VM to flush dirty pages of the output file to disk. This is normally okay, since we should be flushing cold pages. However, when using BtrFS with compression we need to write 128KB at a time when we flush a page. If any page in that 128KB block is written again, then it must be flushed a second time, and so on. Since LLD doesn't write sequentially this causes write amplification. The same 128KB block will end up being flushed multiple times, causing the linker to many times more IO than necessary. We've observed 3-5x faster builds with -no-mmap-output-file when we hit this scenario. The bad scenario only applies to compressed filesystems, which group together multiple pages into a single compressed block. I've tested BtrFS, but the problem will be present for any compressed filesystem on Linux, since it is caused by the VM. Silently ignoring --no-mmap-output-file caused a silent regression when we switched from gold to lld. We pass --no-mmap-output-file to fix this edge case, but since lld silently ignored the flag we didn't realize it wasn't being respected. Benchmark building a 9 GB binary that exposes this edge case. I linked 3 times with --mmap-output-file and 3 times with --no-mmap-output-file and took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM, BtrFS mounted with -compress-force=zstd, and an 80% full disk. | Mode | Time | |---------|-------| | mmap | 894 s | | no mmap | 126 s | When compression is disabled, BtrFS performs just as well with and without mmap on this benchmark. I was unable to reproduce the regression with any binaries in lld-speed-test. Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D69294
* minor doc typo fix / testing github commitRafael Stahl2019-10-281-1/+1
|
* [APInt] Introduce APIntOps::GetMostSignificantDifferentBit()Roman Lebedev2019-10-261-0/+8
| | | | | | | | | | | | | | | | | | Summary: Compare two values, and if they are different, return the position of the most significant bit that is different in the values. Needed for D69387. Reviewers: nikic, spatel, sanjoy, RKSimon Reviewed By: nikic Subscribers: xbolva00, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69439
* [APInt] Add saturating left-shift opsRoman Lebedev2019-10-251-0/+19
| | | | | | | | | | | | | | | | Summary: There are `*_ov()` functions already, so at least for consistency it may be good to also have saturating variants. These may or may not be needed for `ConstantRange`'s `shlWithNoWrap()` Reviewers: spatel, nikic Reviewed By: nikic Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69398
* [APInt] Add saturating multiply opsRoman Lebedev2019-10-251-0/+21
| | | | | | | | | | | | | | | | Summary: There are `*_ov()` functions already, so at least for consistency it may be good to also have saturating variants. These may or may not be needed for `ConstantRange`'s `mulWithNoWrap()` Reviewers: spatel, nikic Reviewed By: nikic Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69397
* Revert "Disable exit-on-SIGPIPE in lldb"Vedant Kumar2019-10-242-16/+1
| | | | | | | This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30. In post-commit review, Pavel pointed out that there's a simpler way to ignore SIGPIPE in lldb that doesn't rely on llvm's handlers.
* Reland "[Support] Add a way to run a function on a detached thread""Sam McCall2019-10-237-61/+132
| | | | | This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237. The immediate callers have been fixed to pass nullopt where appropriate.
* Revert "[Support] Add a way to run a function on a detached thread"Sam McCall2019-10-236-128/+60
| | | | | | This reverts commit 40668abca4d307e02b33345cfdb7271549ff48d0. This causes clang tests to fail, as stacksize=0 is being explicitly passed and is no longer a no-op.
* [Support] Add a way to run a function on a detached threadSam McCall2019-10-236-60/+128
| | | | | | | | | | | | | | | | | | | | | | | This roughly mimics `std::thread(...).detach()` except it allows to customize the stack size. Required for https://reviews.llvm.org/D50993. I've decided against reusing the existing `llvm_execute_on_thread` because it's not obvious what to do with the ownership of the passed function/arguments: 1. If we pass possibly owning functions data to `llvm_execute_on_thread`, we'll lose the ability to pass small non-owning non-allocating functions for the joining case (as it's used now). Is it important enough? 2. If we use the non-owning interface in the new use case, we'll force clients to transfer ownership to the spawned thread manually, but similar code would still have to exist inside `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same non-owning pointer to pthreads and Windows implementations, and would be forced to wrap it in some structure, and deal with its ownership. Patch by Dmitry Kozhevnikov! Differential Revision: https://reviews.llvm.org/D51103
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-191-0/+1
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* Disable exit-on-SIGPIPE in lldbVedant Kumar2019-10-182-1/+16
| | | | | | | | | | | | | | | | | | Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
* Reapply r375051: [support] GlobPattern: add support for `\` and `[!...]`, ↵Jordan Rupprecht2019-10-171-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | and allow `]` in more places Reland r375051 (reverted in r375052) after fixing lld tests on Windows in r375126 and r375131. Original description: Update GlobPattern in libSupport to handle a few more cases. It does not fully match the `fnmatch` used by GNU objcopy since named character classes (e.g. `[[:digit:]]`) are not supported, but this should support most existing use cases (mostly just `*` is what's used anyway). This will be used to implement the `--wildcard` flag in llvm-objcopy to be more compatible with GNU objcopy. This is split off of D66613 to land the libSupport changes separately. The llvm-objcopy part will land soon. Reviewers: jhenderson, MaskRay, evgeny777, espindola, alexshap Reviewed By: MaskRay Subscribers: nickdesaulniers, emaste, arichardson, hiraditya, jakehehrlich, abrachet, seiya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66613 llvm-svn: 375149
* Revert [support] GlobPattern: add support for `\` and `[!...]`, and allow ↵Jordan Rupprecht2019-10-161-16/+7
| | | | | | | | | | `]` in more places This reverts r375051 (git commit a409afaad64ce83ea44cc30ee5f96b6e613a6e98) The patch does not work on Windows due to `\` in filenames being interpreted as escaping rather than literal path separators when used by lld linker scripts. llvm-svn: 375052
* [support] GlobPattern: add support for `\` and `[!...]`, and allow `]` in ↵Jordan Rupprecht2019-10-161-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | more places Summary: Update GlobPattern in libSupport to handle a few more cases. It does not fully match the `fnmatch` used by GNU objcopy since named character classes (e.g. `[[:digit:]]`) are not supported, but this should support most existing use cases (mostly just `*` is what's used anyway). This will be used to implement the `--wildcard` flag in llvm-objcopy to be more compatible with GNU objcopy. This is split off of D66613 to land the libSupport changes separately. The llvm-objcopy part will land soon. Reviewers: jhenderson, MaskRay, evgeny777, espindola, alexshap Reviewed By: MaskRay Subscribers: nickdesaulniers, emaste, arichardson, hiraditya, jakehehrlich, abrachet, seiya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66613 undo objcopy changes to make this libsupport only llvm-svn: 375051
* RedirectingFileSystem::openFileForRead - replace bitwise & with boolean && ↵Simon Pilgrim2019-10-161-1/+1
| | | | | | | | to fix warning Seems to be just a typo - now matches other instances which do something similar llvm-svn: 374995
* RealFile - fix self-initialization warning in constructor.Simon Pilgrim2019-10-161-3/+3
| | | | llvm-svn: 374994
* [Reland][VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-10/+35
| | | | | | | | | | | | | | | | | | | | RedirectingFS Before this patch, changing the working directory of the RedirectingFS would just forward to its external file system. This prevented us from having a working directory that only existed in the VFS mapping. This patch adds support for a virtual working directory in the RedirectingFileSystem. It now keeps track of its own WD in addition to updating the WD of the external file system. This ensures that we can still fall through for relative paths. This change was originally motivated by the reproducer infrastructure in LLDB where we want to deal transparently with relative paths. Differential revision: https://reviews.llvm.org/D65677 llvm-svn: 374955
* Revert "[VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-35/+10
| | | | | | | | | | | RedirectingFS" This reverts the original commit and the follow up: Revert "[VirtualFileSystem] Support virtual working directory in the RedirectingFS" Revert "[test] Update YAML mapping in VirtualFileSystemTest" llvm-svn: 374935
* [VirtualFileSystem] Support virtual working directory in the RedirectingFSJonas Devlieghere2019-10-151-10/+35
| | | | | | | | | | | | | | | | | | Before this patch, changing the working directory of the RedirectingFS would just forward to its external file system. This prevented us from having a working directory that only existed in the VFS mapping. This patch adds support for a virtual working directory in the RedirectingFileSystem. It now keeps track of its own WD in addition to updating the WD of the external file system. This ensures that we can still fall through for relative paths. This change was originally motivated by the reproducer infrastructure in LLDB where we want to deal transparently with relative paths. Differential revision: https://reviews.llvm.org/D65677 llvm-svn: 374917
* [Alignment][NFC] Move and type functions from MathExtras to AlignmentGuillaume Chatelet2019-10-141-3/+3
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68942 llvm-svn: 374773
* [FileCheck] Implement --ignore-case option.Kai Nacke2019-10-112-2/+10
| | | | | | | | | | | | The FileCheck utility is enhanced to support a `--ignore-case` option. This is useful in cases where the output of Unix tools differs in case (e.g. case not specified by Posix). Reviewers: Bigcheese, jakehehrlich, rupprecht, espindola, alexshap, jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D68146 llvm-svn: 374538
* [Stats] Add ALWAYS_ENABLED_STATISTIC enabled regardless of LLVM_ENABLE_STATS.Volodymyr Sapsai2019-10-111-14/+13
| | | | | | | | | | | | | | | | | | | | | The intended usage is to measure relatively expensive operations. So the cost of the statistic is negligible compared to the cost of a measured operation and can be enabled all the time without impairing the compilation time. rdar://problem/55715134 Reviewers: dsanders, bogner, rtereshin Reviewed By: dsanders Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68252 llvm-svn: 374490
* win: Move Parallel.h off concrt to cross-platform codeNico Weber2019-10-101-30/+1
| | | | | | | | | | | | | | | | | | | | | r179397 added Parallel.h and implemented it terms of concrt in 2013. In 2015, a cross-platform implementation of the functions has appeared and is in use everywhere but on Windows (r232419). r246219 hints that <thread> had issues in MSVC2013, but r296906 suggests they've been fixed now that we require 2015+. So remove the concrt code. It's less code, and it sounds like concrt has conceptual and performance issues, see PR41198. I built blink_core.dll in a debug component build with full symbols and in a release component build without any symbols. I couldn't measure a performance difference for linking blink_core.dll before and after this patch. Differential Revision: https://reviews.llvm.org/D68820 llvm-svn: 374421
* Print quoted backslashes in LLVM IR as \\ instead of \5CReid Kleckner2019-10-101-1/+3
| | | | | | | | | This improves readability of Windows path string literals in LLVM IR. The LLVM assembler has supported \\ in IR strings for a long time, but the lexer doesn't tolerate escaped quotes, so they have to be printed as \22 for now. llvm-svn: 374415
* Revert "[FileCheck] Implement --ignore-case option."Dmitri Gribenko2019-10-102-2614/+2606
| | | | | | | This reverts commit r374339. It broke tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19066 llvm-svn: 374359
* [FileCheck] Implement --ignore-case option.Kai Nacke2019-10-102-2606/+2614
| | | | | | | | | | | | The FileCheck utility is enhanced to support a `--ignore-case` option. This is useful in cases where the output of Unix tools differs in case (e.g. case not specified by Posix). Reviewers: Bigcheese, jakehehrlich, rupprecht, espindola, alexshap, jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D68146 llvm-svn: 374339
* Unify the two CRC implementationsHans Wennborg2019-10-093-138/+72
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* Expose ProvidePositionalOption as a public APIMehdi Amini2019-10-051-1/+1
| | | | | | | | | | | | | | The motivation is to reuse the key value parsing logic here to parse instance specific pass options within the context of MLIR. The primary functionality exposed is the "," splitting for arrays and the logic for properly handling duplicate definitions of a single flag. Patch by: Parker Schuh <parkers@google.com> Differential Revision: https://reviews.llvm.org/D68294 llvm-svn: 373815
* [Support, ARM64] Define getHostCPUFeatures for Windows on ARM64 platformMartin Storsjo2019-10-021-0/+11
| | | | | | | | Patch by Adam Kallai! Differential Revision: https://reviews.llvm.org/D68139 llvm-svn: 373445
* [FileCheck] Move private interface to its own headerThomas Preud'homme2019-10-012-0/+622
| | | | | | | | | | | | | | | | | | | Summary: Most of the class definition in llvm/include/llvm/Support/FileCheck.h are actually implementation details that should not be relied upon. This commit moves all of it in a new header file under llvm/lib/Support/FileCheck. It also takes advantage of the code movement to put the code into a new llvm::filecheck namespace. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield Tags: #llvm Differential Revision: https://reviews.llvm.org/D67649 llvm-svn: 373395
* VirtualFileSystem - replace dyn_cast<>+assert with cast<> calls. NFCI.Simon Pilgrim2019-10-011-8/+5
| | | | | | Silences a number of clang static analyzer null dereference warnings. llvm-svn: 373325
* [FileCheck] Remove implementation types from APIThomas Preud'homme2019-09-301-19/+24
| | | | | | | | | | | | | | | | | Summary: Remove use of FileCheckPatternContext and FileCheckString concrete types from FileCheck API to allow moving it and the other implementation only only declarations into a private header file. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68186 llvm-svn: 373211
* Regex: Make "match" and "sub" const member functionsThomas Preud'homme2019-09-242-13/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The Regex "match" and "sub" member functions were previously not "const" because they wrote to the "error" member variable. This commit removes those assignments, and instead assumes that the validity of the regex is already known after the initial compilation of the regular expression. As a result, these member functions were possible to make "const". This makes it easier to do things like pre-compile Regexes up-front, and makes "match" and "sub" thread-safe. The error status is now returned as an optional output, which also makes the API of "match" and "sub" more consistent with each other. Also, some uses of Regex that could be refactored to be const were made const. Patch by Nicolas Guillemot Reviewers: jankratochvil, thopre Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67241 llvm-svn: 372764
* [SystemZ] Support z15 processor nameUlrich Weigand2019-09-201-1/+1
| | | | | | | | | | | The recently announced IBM z15 processor implements the architecture already supported as "arch13" in LLVM. This patch adds support for "z15" as an alternate architecture name for arch13. The patch also uses z15 in a number of places where we used arch13 as long as the official name was not yet announced. llvm-svn: 372435
* Fix compile-time regression caused by rL371928Daniel Sanders2019-09-181-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Also fixup rL371928 for cases that occur on our out-of-tree backend There were still quite a few intermediate APInts and this caused the compile time of MCCodeEmitter for our target to jump from 16s up to ~5m40s. This patch, brings it back down to ~17s by eliminating pretty much all of them using two new APInt functions (extractBitsAsZExtValue(), insertBits() but with a uint64_t). The exact conditions for eliminating them is that the field extracted/inserted must be <=64-bit which is almost always true. Note: The two new APInt API's assume that APInt::WordSize is at least 64-bit because that means they touch at most 2 APInt words. They statically assert that's true. It seems very unlikely that someone is patching it to be smaller so this should be fine. Reviewers: jmolloy Reviewed By: jmolloy Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67686 llvm-svn: 372243
* Revert "r372201: [Support] Replace function with function_ref in ↵Ilya Biryukov2019-09-181-1/+1
| | | | | | | | | | | writeFileAtomically. NFC" function_ref causes calls to the function to be ambiguous, breaking compilation. Reverting for now. llvm-svn: 372202
* [Support] Replace function with function_ref in writeFileAtomically. NFCIlya Biryukov2019-09-181-1/+1
| | | | | | | | | | | | | | | | | | | Summary: The latter is slightly more efficient and communicates the intent of the API: writeFileAtomically does not own or copy the callback, it merely calls it at some point. Reviewers: jkorous Reviewed By: jkorous Subscribers: hiraditya, dexonsmith, jfb, llvm-commits, cfe-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67584 llvm-svn: 372201
* [ARM] VFPv2 only supports 16 D registers.Eli Friedman2019-09-171-5/+3
| | | | | | | | | | | | | | | | | | | | r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers. In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions. This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32". Differential Revision: https://reviews.llvm.org/D67375 llvm-svn: 372186
* [Reproducer] Add reproducer dump command.Jonas Devlieghere2019-09-131-10/+12
| | | | | | | | | | | This adds a reproducer dump commands which makes it possible to inspect a reproducer from inside LLDB. Currently it supports the Files, Commands and Version providers. I'm planning to add support for the GDB Remote provider in a follow-up patch. Differential revision: https://reviews.llvm.org/D67474 llvm-svn: 371909
* [Support] Add overload writeFileAtomically(std::function Writer)Jan Korous2019-09-131-16/+47
| | | | | | Differential Revision: https://reviews.llvm.org/D67424 llvm-svn: 371890
* Move LLVM_ENABLE_ABI_BREAKING_CHECKS variables to their own fileEric Christopher2019-09-103-15/+25
| | | | | | | | | | | | | so that you don't have to link Error.o and all of its dependencies. In more detail: global initializers in Error.o can't be elided with -ffunction-sections/-gc-sections since they always need to be run causing a fairly significant binary bloat if all you want is the ABI breaking checks code. Differential Revision: https://reviews.llvm.org/D67387 llvm-svn: 371561
* [Support] Add writeFileAtomically() to FileUtilitiesJan Korous2019-09-051-0/+35
| | | | | | Differential Revision: https://reviews.llvm.org/D66859 llvm-svn: 371103
* Fix time-trace breaking flame graph assumptionsRussell Gallop2019-09-051-12/+37
| | | | | | | | | | | | | | | | | | | -ftime-trace could break flame-graph assumptions on Windows, with an inner scope overrunning outer scopes. This was due to the way that times were truncated. Changed this so time_points for the flame-graph are truncated instead of durations, preserving the relative order of event starts and ends. I have tried to retain the extra precision for the totals, which count thousands or millions of events. Added assert to check this property holds in future. Fixes PR43043 Differential Revision: https://reviews.llvm.org/D66411 llvm-svn: 371039
* Win: handle \\?\UNC\ prefix in realPathFromHandle (PR43204)Hans Wennborg2019-09-051-6/+12
| | | | | | | | | | | | | | | | | | | | After r361885, realPathFromHandle() ends up getting called on the working directory on each Clang invocation. This unveiled that the code didn't work for paths on network shares. For example, if one maps the local dir c:\src\tmp to x: net use x: \\localhost\c$\tmp and run e.g. "clang -c foo.cc" in x:\, realPathFromHandle will get \\?\UNC\localhost\c$\src\tmp\ back from GetFinalPathNameByHandleW, and would strip off the initial \\?\ prefix, ending up with a path that doesn't work. This patch makes the prefix stripping a little smarter to handle this case. Differential revision: https://reviews.llvm.org/D67166 llvm-svn: 371035
* [X86] Add support for avx512bf16 for __builtin_cpu_supports and ↵Craig Topper2019-09-041-2/+7
| | | | | | compiler-rt's cpu indicator. llvm-svn: 370915
* [FileCheck] Forbid using var defined on same lineThomas Preud'homme2019-09-021-36/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Commit r366897 introduced the possibility to set a variable from an expression, such as [[#VAR2:VAR1+3]]. While introducing this feature, it introduced extra logic to allow using such a variable on the same line later on. Unfortunately that extra logic is flawed as it relies on a mapping from variable to expression defining it when the mapping is from variable definition to expression. This flaw causes among other issues PR42896. This commit avoids the problem by forbidding all use of a variable defined on the same line, and removes the now useless logic. Redesign will be done in a later commit because it will require some amount of refactoring first for the solution to be clean. One example is the need for some sort of transaction mechanism to set a variable temporarily and from an expression and rollback if the CHECK pattern does not match so that diagnostics show the right variable values. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D66141 llvm-svn: 370663
* [yaml2obj][obj2yaml] - Use a single "Other" field instead of "Other", ↵George Rimar2019-08-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Visibility" and "StOther". Currenly we can encode the 'st_other' field of symbol using 3 fields. 'Visibility' is used to encode STV_* values. 'Other' is used to encode everything except the visibility, but it can't handle arbitrary values. 'StOther' is used to encode arbitrary values when 'Visibility'/'Other' are not helpfull enough. 'st_other' field is used to encode symbol visibility and platform-dependent flags and values. Problem to encode it is that it consists of Visibility part (STV_* values) which are enumeration values and the Other part, which is different and inconsistent. For MIPS the Other part contains flags for all STO_MIPS_* values except STO_MIPS_MIPS16. (Like comment in ELFDumper says: "Someones in their infinite wisdom decided to make STO_MIPS_MIPS16 flag overlapped with other ST_MIPS_xxx flags."...) And for PPC64 the Other part might actually encode any value. This patch implements custom logic for handling the st_other and removes 'Visibility' and 'StOther' fields. Here is an example of a new YAML style this patch allows: - Name: foo Other: [ 0x4 ] - Name: bar Other: [ STV_PROTECTED, 4 ] - Name: zed Other: [ STV_PROTECTED, STO_MIPS_OPTIONAL, 0xf8 ] Differential revision: https://reviews.llvm.org/D66886 llvm-svn: 370472
* [X86] Remove what little support we had for MPXCraig Topper2019-08-291-1/+0
| | | | | | | | | | | | | | | -Deprecate -mmpx and -mno-mpx command line options -Remove CPUID detection of mpx for -march=native -Remove MPX from all CPUs -Remove MPX preprocessor define I've left the "mpx" string in the backend so we don't fail on old IR, but its not connected to anything. gcc has also deprecated these command line options. https://www.phoronix.com/scan.php?page=news_item&px=GCC-Patch-To-Drop-MPX Differential Revision: https://reviews.llvm.org/D66669 llvm-svn: 370393
* Add error handling to the DataExtractor classPavel Labath2019-08-271-41/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is motivated by D63591, where we realized that there isn't a really good way of telling whether a DataExtractor is reading actual data, or is it just returning default values because it reached the end of the buffer. This patch resolves that by providing a new "Cursor" class. A Cursor object encapsulates two things: - the current position/offset in the DataExtractor - an error object Storing the error object inside the Cursor enables one to use the same pattern as the std::{io}stream API, where one can blindly perform a sequence of reads and only check for errors once at the end of the operation. Similarly to the stream API, as soon as we encounter one error, all of the subsequent operations are skipped (return default values) too, even if the would suceed with clear error state. Unlike the std::stream API (but in line with other llvm APIs), we force the error state to be checked through usage of llvm::Error. Reviewers: probinson, dblaikie, JDevlieghere, aprantl, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63713 llvm-svn: 370042
* Do a sweep of symbol internalization. NFC.Benjamin Kramer2019-08-231-1/+1
| | | | llvm-svn: 369803
OpenPOWER on IntegriCloud