- Nov 22, 2019
-
-
Artem Dergachev authored
Slightly improves static analysis speed. Differential Revision: https://reviews.llvm.org/D70150
-
Craig Topper authored
Add explicit setOperation actions for some to match their none strict counterparts. This isn't required, but makes the code self documenting that we didn't forget about strict fp. I've used LibCall instead of Expand since that's more explicitly what we want. Only lrint/llrint/lround/llround are missing now.
-
Craig Topper authored
The Expand code would fall back to LibCall, but this makes it more explicit.
-
Artem Dergachev authored
Push the test separately ahead of time in order to find out whether our Memory Sanitizer bots will be able to find the problem. If not, I'll add a much more expensive test that repeats the current test multiple times in order to show up on normal buildbots. I really apologize for the potential temporary inconvenience! I'll commit the fix as soon as I get the signal. Differential Revision: https://reviews.llvm.org/D69962
-
Pengfei Wang authored
float node This patch add an option 'disable-strictnode-mutation' to prevent strict node mutating to an normal node. So we can make sure that the patch which sets strict-node as legal works correctly. Patch by Chen Liu(LiuChen3) Differential Revision: https://reviews.llvm.org/D70226
-
Alina Sbirlea authored
The verification inside loop passes should be done under the VerifyMemorySSA flag (enabled by EXPESIVE_CHECKS or explicitly with opt), in order to not add to compile time during regular builds.
-
Marco Vanotti authored
Summary: This commit moves the `DiscardOutput` function in FuzzerIO to FuzzerUtil, so fuchsia can have its own specialized version. In fuchsia, accessing `/dev/null` is not supported, and there's nothing similar to a file that discards everything that is written to it. The way of doing something similar in fuchsia is by using `fdio_null_create` and binding that to a file descriptor with `fdio_bind_to_fd`. This change should fix one of the issues with the `-close_fd_mask` flag in libfuzzer, in which closing stdout was not working due to `fopen("/dev/null", "w")` returning `NULL`. Reviewers: kcc, aarongreen Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69593
-
Nathan Ridge authored
Differential Revision: https://reviews.llvm.org/D67536
-
Craig Topper authored
[LegalizeDAG][X86] Add support for turning STRICT_FADD/SUB/MUL/DIV into libcalls. Use it for fp128 on x86-64. This requires a minor hack for f32/f64 strict fadd/fsub to avoid turning those into libcalls.
-
Craig Topper authored
The prevents LegalizeVectorOps from scalarizing them. We'll need to remove the X86 mutation code when we add isel patterns.
-
Craig Topper authored
[X86] Remove regcall calling convention from fp-strict-scalar.ll. Add 32-bit and 64-bit check prefixes. The regcall was making 32-bit mode pass things in xmm registers which made 32-bit and 64-bit more similar. But I have upcoming patches that require them to be separated anyway.
-
Alexander Shaposhnikov authored
This diff adds support for -extract. Test plan: make check-all Differential revision: https://reviews.llvm.org/D70522
-
Petr Hosek authored
We don't have a full sysroot yet, so for now we only include compiler support and compiler-rt builtins, the rest of the runtimes will get enabled later. Differential Revision: https://reviews.llvm.org/D70477
-
Marco Vanotti authored
Summary: This commit fixes part of the issues with stack unwinding in fuchsia for arm64 and x86_64. It consists of multiple fixes: (1) The cfa_offset calculation was wrong, instead of pointing to the previous stack pointer, it was pointing to the current one. It worked in most of the cases because the crashing functions already had a prologue and had their cfa information relative to another register. The fix consists on adding a constant that can be used to calculate the crashing function's stack pointer, and base all the cfi information relative to that offset. (2) (arm64) Due to errors with the syntax for the dwarf information, most of the `OP_NUM` macros were not working. The problem was that they were referred to as `r##NUM` (like `r14`), when it should have been `x##num` (like `x14`), or even without the x. (3) (arm64) The link register was being considered a part of the main registers (`r30`), when in the real struct it has its own field. Given that the link register is in the same spot in the struct as r[30] would be, and that C++ doesn't care about anything, the calculation was still correct. (4) (x86_64) The stack doesn't need to be aligned to 16 bytes when we jump to the trampoline function, but it needs to be before performing call instructions. Encoding that logic in cfi information was tricky, so we decided to make the cfa information relative to `rbp` and align `rsp`. Note that this could have been done using another register directly, but it seems cleaner to make a new fake stack frame. There are some other minor changes like adding a `brk 1` instruction in arm64 to make sure that we never return to the crash trampoline (similar to what we do in x86_64). Sadly this commit does not fix unwinding for all use cases for arm64. Crashing functions that do not add information related to the return column in their cfi information will fail to unwind due to a bug in libunwinder. Reviewers: mcgrathr, jakehehrlich, phosek, kcc, aarongreen Subscribers: aprantl, kristof.beyls, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69579
-
Philip Reames authored
We may end up with a case where we have a widenable branch above the loop, but not all widenable branches within the loop have been removed. Since a widenable branch inhibit SCEVs ability to reason about exit counts (by design), we have a tradeoff between effectiveness of this optimization and allowing future widening of the branches within the loop. LoopPred is thought to be one of the most important optimizations for range check elimination, so let's pay the cost.
-
Adrian Prantl authored
-
Luís Marques authored
Summary: Add support for resolving `R_RISCV_32_PCREL` relocations. Those aren't actually resolved AFAIK, but support is still needed to avoid llvm-dwarfdump errors. The use of these relocations was introduced in D66419 but the corresponding resolving wasn't added then. The test adds a check that should catch future unresolved relocations. Reviewers: asb, lenary Reviewed By: asb Tags: #llvm Differential Revision: https://reviews.llvm.org/D70204
-
David Tellenbach authored
Summary: The insertion of most CFI instructions during AArch64 frame lowering can be disabled (e.g. using the function attribute `nounwind`). This patch enables conditional insertion for one more CFI instruction. Reviewers: t.p.northover, ostannard Reviewed By: ostannard Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70129
-
Marco Vanotti authored
Summary: This commit fixes the check in the return value from the `DuplicateFile` function, which returns a new file descriptor. `DuplicateFile` can return 0 if that file descriptor is available (for example, if stdin has already been closed). In particular, this could cause a bug with the `-close_fd_mask` flag in some platforms: just call the fuzzer with stdin closed and the `-close_fd_mask=2` flag, and stderr will not be muted. Example fuzzer: ``` extern "C" int LLVMFuzzerTestOneInput(const uint8_t* Data, size_t Size) { fprintf(stderr, "STDERR\n"); fprintf(stdout, "STDOUT\n"); return 0; } ``` Invocation (muting both stderr and stdout): ``` ./test -close_fd_mask=3 -runs=1 0<&- INFO: Seed: 1155116940 INFO: Loaded 1 modules (1 inline 8-bit counters): 1 [0x48b020, 0x48b021), INFO: Loaded 1 PC tables (1 PCs): 1 [0x478dc8,0x478dd8), INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes STDERR INFO: A corpus is not provided, starting from an empty corpus STDERR Done 2 runs in 0 second(s) ``` Reviewers: mcgrathr, jakehehrlich, phosek, kcc, aarongreen Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68775
-
Julian Lettner authored
rdar://57365733
-
Philip Reames authored
This is a follow on to aaea2480. In post commit discussion, Artur and I realized we could cleanup the code using Uses; this patch does so.
-
Joel E. Denny authored
Without this patch, `FILECHECK_OPTS` isn't propagated to FileCheck's test suite so that `FILECHECK_OPTS` doesn't inadvertently affect test results by affecting the output of FileCheck calls under test. As a result, `FILECHECK_OPTS` is useless for debugging FileCheck's test suite. In `llvm/test/FileCheck/lit.local.cfg`, this patch provides a new subsitution, `%ProtectFileCheckOutput`, to address this problem for both `FILECHECK_OPTS` and the deprecated `FILECHECK_DUMP_INPUT_ON_FAILURE`. The rest of the patch uses `%ProtectFileCheckOutput` throughout the test suite Fixes PR40284. Reviewed By: probinson, thopre Differential Revision: https://reviews.llvm.org/D65121
-
- Nov 21, 2019
-
-
Luís Marques authored
Summary: These relocations had a suspicious resolution logic, given their name. This patch makes the resolution match the LLD one, which makes more sense. Reviewers: asb, lenary, HsiangKai, jrtc27 Reviewed By: HsiangKai Tags: #llvm Differential Revision: https://reviews.llvm.org/D70396
-
Hiroshi Yamauchi authored
Summary: (Split of off D67120) SelectionDAG::shouldOptForSize changes for profile guided size optimization. Reviewers: davidxl Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70095
-
Vedant Kumar authored
Bit-Tracking Dead Code Elimination (bdce) do not mark dbg.value as undef after deleting instruction. which shows invalid state of variable in debugger. This patches fixes this by marking the dbg.value as undef which depends on dead instruction. This fixes https://bugs.llvm.org/show_bug.cgi?id=41925 Patch by kamlesh kumar! Differential Revision: https://reviews.llvm.org/D70040
-
Alexey Bataev authored
-
Jonas Devlieghere authored
Print a regular newline at the end of the help output. The current string literal seems to throw off shells.
-
Jonas Devlieghere authored
There's no point in preventing this command from running during replay. We should simulate the same crash as during capture.
-
Jonas Devlieghere authored
Improve the message printed when LLDB crashes by asking the user to replay the reproducer before attaching it to a bugreport.. ******************** Crash reproducer for lldb version 10.0.0 (git@github.com:llvm/llvm-project.git revision ...) clang revision ... llvm revision ... Reproducer written to '/path/to/reproducer' Before attaching the reproducer to a bug report: - Look at the directory to ensure you're willing to share its content. - Make sure the reproducer works by replaying the reproducer. Replay the reproducer with the following command: ./bin/lldb -replay /path/to/reproducer ********************
-
Jonas Devlieghere authored
As discussed in https://reviews.llvm.org/D70324.
-
Kazu Hirata authored
Summary: This patch moves various checks from ThreadEdge to new function TryThreadEdge The rational behind this is that I'd like to use ThreadEdge without its checks in my upcoming patch. This patch preserves lightweight checks as assertions in ThreadEdge. ThreadEdge does not repeat the cost check, however. Reviewers: wmi Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70338
-
Craig Topper authored
The custom code just emits a libcall, but we can do the same with generic code. The only difference is that the generic code can form tail calls where the custom code couldn't. This is responsible for the test changes. This avoids needing to modify the Custom handling for strict fp.
-
Craig Topper authored
This should be turned into a libcall to fmal. We already do it correctly, but we had no test to confirm.
-
Stefan Pintilie authored
This patch will add -mcpu=future into clang for PowerPC. A CPU type is required for work that may possibly be enabled for some future Power CPU. The CPU type future will serve that purpose. This patch introduces no new functionality. It is an incremental patch on top of which Power PC work for some future CPU can be done. Differential Revision: https://reviews.llvm.org/D70262
-
Jonas Devlieghere authored
The unsplit test is timing out on GreenDragon's sanitized bot. By splitting the test we avoid this issue and increase parallelism.
-
Adrian Prantl authored
even in DWARF 4 and earlier. This allows the debugger to recognize them as direct functions as opposed to Objective-C methods. <rdar://problem/57327663> Differential Revision: https://reviews.llvm.org/D70544
-
Tom Stellard authored
Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
-
Philip Reames authored
As a reminder, a "widenable branch" is the pattern "br i1 (and i1 X, WC()), label %taken, label %untaken" where "WC" is the widenable condition intrinsics. The semantics of such a branch (derived from the semantics of WC) is that a new condition can be added into the condition arbitrarily without violating legality. Broaden the definition in two ways: Allow swapped operands to the br (and X, WC()) form Allow widenable branch w/trivial condition (i.e. true) which takes form of br i1 WC() The former is just general robustness (e.g. for X = non-instruction this is what instcombine produces). The later is specifically important as partial unswitching of a widenable range check produces exactly this form above the loop. Differential Revision: https://reviews.llvm.org/D70502
-
Philip Reames authored
[Tests] Autogenerate a bunch of SCEV trip count tests for readability. Will likely merge some of these files soon.
-
Alexey Bataev authored
Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
-