- 16 Sep, 2021 40 commits
-
-
Philip Reames authored
-
Nikita Popov authored
getMetadata() currently uses a weird API where it populates a structure passed to it, and optionally merges into it. Instead, we can return the AAMDNodes and provide a separate merge() API. This makes usages more compact. Differential Revision: https://reviews.llvm.org/D109852
-
Aaron Green authored
On Fuchsia, killing or exiting a process that has a thread listening to its own process's debugger exception channel can hang. Zircon may kill all the threads, send a synthetic exceptions to debugger, and wait for the debugger to have received them. This means the thread listening to the debug exception channel may be killed even as Zircon is waiting for that thread to drain the exception channel, and the process can become stuck in a half-dead state. This situation is "weird" as it only arises when a process is trying to debug itself. Unfortunately, this is exactly the scenario for libFuzzer on Fuchsia: FuzzerUtilFuchsia spawns a crash-handling thread that acts like a debugger in order to be able to rewrite the crashed threads stack and resume them into libFuzzer's usual POSIX signal handlers. In practice, approximately 25% of fuzzers appear to hang on exit, after generating output and artifacts. These processes hang around until the platform is torn done, which is typically a ClusterFuzz VM. Thus, real-world impact has been somewhat mitigated. The issue should still be resolved for local users, though. This change improves the behavior of exit() in libFuzzer by adding an atexit handler which closes an event shared with the crash handling thread. This signals to the crash handler that it should close the exception channel and be joined before the process actually exits. Reviewed By: charco Differential Revision: https://reviews.llvm.org/D109258
-
Rob Suderman authored
TosaOp defintion had an artificial constraint that the input/output types needed to be ranked to invoke the quantization builder. This is correct as an unranked tensor could still be quantized. Reviewed By: NatashaKnk Differential Revision: https://reviews.llvm.org/D109863
-
Amy Huang authored
This test checks that timers are working and printing as expected. I also seem to have changed the order of the timers in my globals refactoring patch, so I fixed it here. Differential Revision: https://reviews.llvm.org/D109904
-
Artem Belevich authored
Otherwise, we fail to compile calls to CUDA kernels that are static members. Differential Revision: https://reviews.llvm.org/D108787
-
Jake Egan authored
AIX and z/OS lack Objective-C support, so mark these tests as unsupported for AIX and z/OS. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D109060
-
Craig Topper authored
SimplifyDemandedBits can turn srl into sra if the bits being shifted in aren't demanded. This patch can recover the original sra in some cases. I've renamed the tablegen class for detecting W users since the "overflowing operator" term I originally borrowed from Operator.h does not include srl. Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D109162
-
Amy Huang authored
This patch removes globals from the lldCOFF library, by moving globals into a context class (COFFLinkingContext) and passing it around wherever it's needed. See https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html for context about removing globals from LLD. I also haven't moved the `driver` or `config` variables yet. Differential Revision: https://reviews.llvm.org/D109634
-
Jonas Devlieghere authored
This is a protected function that's not implemented.
-
Vang Thao authored
In https://reviews.llvm.org/D100481, forceful inline of all non-kernel functions using lds was disabled since AMDGPULowerModuleLDS pass now handles static lds. However that pass does not handle extern lds so non-kernel functions using extern lds must sill be inline. Reviewed By: hsmhsm, arsenm Differential Revision: https://reviews.llvm.org/D109773
-
Arthur Eubanks authored
This makes some tests in vector-reductions-logical.ll more stable when applying D108837. The cost of branching is higher when vector ops are involved due to potential SLP transformations. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D108935
-
Saleem Abdulrasool authored
The trailing `>` was missing, which resulted in the reference not being processed properly.
-
Dávid Bolvanský authored
If power is even: powi(-x, p) -> powi(x, p) powi(fabs(x), p) -> powi(x, p) powi(copysign(x, y), p) -> powi(x, p)
-
Dávid Bolvanský authored
-
Wenlei He authored
Turn on `use-context-cost-for-preinliner` to use context-sensitive byte size cost for preinliner decisions by default. This is a more accurate proxy of inline cost than profile size. We tested on our large workload that it delivers measureable CPU improvement. Differential Revision: https://reviews.llvm.org/D109893
-
Corentin Jabot authored
This update the UAX tables to support new Unicode 14 identifiers.
-
Fangrui Song authored
-
Aaron Ballman authored
-
Aart Bik authored
We are having issues running the integration test of the sparse compiler on AArch64 (crashing in the lib). This revision adds more assertions. Reviewed By: jsetoain Differential Revision: https://reviews.llvm.org/D109861
-
Sjoerd Meijer authored
-
Nicolas Vasilache authored
-
cchen authored
This patch supports construct trait set selector by using the existed declare variant infrastructure inside `OMPContext` and simd selector is currently not supported. The goal of this patch is to pass the declare variant test inside sollve test suite. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D109635
-
Alfonso Gregory authored
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D107717
-
Nehal J Wani authored
When `libcxx` or `libcxxabi` is built with `-DLLVM_USE_SANITIZER=MemoryWithOrigins` **and** `-DLIBCXX[ABI]_USE_COMPILER_RT=ON`, all of the `LIBCXX[ABI]_SUPPORTS_*_FLAG` checks fail, since the value of `CMAKE_REQUIRED_FLAGS` is not set correctly. Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=51774 Reviewed By: #libc, #libc_abi, compnerd, ldionne Differential Revision: https://reviews.llvm.org/D109342
-
Matthew Voss authored
Specify the C and C++ standards explicitly for this test. This avoids failures for drivers that default to older standards. Differential Revision: https://reviews.llvm.org/D109857
-
Arnold Schwaighofer authored
Summary: Introduce a new frontend flag `-fswift-async-fp={auto|always|never}` that controls how code generation sets the Swift extended async frame info bit. There are three possibilities: * `auto`: which determines how to set the bit based on deployment target, either statically or dynamically via `swift_async_extendedFramePointerFlags`. * `always`: default, always set the bit statically, regardless of deployment target. * `never`: never set the bit, regardless of deployment target. Differential Revision: https://reviews.llvm.org/D109451
-
Kazu Hirata authored
-
Michael Liao authored
-
Erich Keane authored
-
Kadir Cetinkaya authored
Don't create a useless functional patch with only filename in it when there is only include directives to be patched but they're not requested. Differential Revision: https://reviews.llvm.org/D109880
-
Yaxun (Sam) Liu authored
Storing the vtable field of an object should use the same address space as the this pointer. Currently it is assumed to be addr space 0 but this may not be true. This assumption (added in 054cc3b1) caused issues for the out-of-tree CHERI targets. Reviewed by: John McCall, Alexander Richardson Differential Revision: https://reviews.llvm.org/D109841
-
Kadir Cetinkaya authored
Don't install clang-tidy checks and IncludeFixer or process clang diags when they're going to be dropped. Also disables analysis for some warnings completely. Differential Revision: https://reviews.llvm.org/D109884
-
Jake Egan authored
This patch increases the expected line number for one of the checks so that it doesn't have to be updated for any added/removed lines in the RUN section. This change is in preparation for the following patch: https://reviews.llvm.org/D109060 Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D109541
-
Doug Gregor authored
Introduce a new command-line flag `-swift-async-fp={auto|always|never}` that controls how code generation sets the Swift extended async frame info bit. There are three possibilities: * `auto`: which determines how to set the bit based on deployment target, either statically or dynamically via `swift_async_extendedFramePointerFlags`. * `always`: the default, always set the bit statically, regardless of deployment target. * `never`: never set the bit, regardless of deployment target. Patch by Doug Gregor <dgregor@apple.com> Reviewed By: doug.gregor Differential Revision: https://reviews.llvm.org/D109392
-
zhijian authored
Summary: add a new API seek for the Cursor class in the DataExtractor.cpp Reviewers: James Henderson, Fangrui Song Differential Revision: https://reviews.llvm.org/D109603
-
Zarko Todorovski authored
Remove the previous error and add support for special handling of small complex types as in PPC64 ELF ABI. As in, generate code to load from varargs location and pack it in a temp variable, then return a pointer to the struct. Reviewed By: sfertile Differential Revision: https://reviews.llvm.org/D106393
-
Bjorn Pettersson authored
Change the asan-module pass into a MODULE_PASS_WITH_PARAMS in the pass registry, and add a single parameter called 'kernel' that can be set instead of having a special pass name 'kasan-module' to trigger that special pass config. Main reason is to make sure that we have a unique mapping from ClassName to PassName in the new passmanager framework, making it possible to correctly identify the passes when dealing with options such as -print-after and -print-pipeline-passes. This is a follow-up to D105006 and D105007.
-
Bjorn Pettersson authored
Split ThreadSanitizerPass into ThreadSanitizerPass (as a function pass) and ModuleThreadSanitizerPass (as a module pass). Main reason is to make sure that we have a unique mapping from ClassName to PassName in the new passmanager framework, making it possible to correctly identify the passes when dealing with options such as -print-after and -print-pipeline-passes. This is a follow-up to D105006 and D105007.
-