- Jan 20, 2021
-
-
Stephen Kelly authored
-
Stella Laurenzo authored
* This isn't exclusive with other mechanisms for more ODS centric op definitions, but based on discussions, we feel that we will always benefit from a python escape hatch, and that is the most natural way to write things that don't fit the mold. * I suspect this facility needs further tweaking, and once it settles, I'll document it and add more tests. * Added extensions for linalg, since it is unusable without them and continued to evolve my e2e example. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94752
-
Sam Clegg authored
Object files (and the output --relocatable) should never define __indirect_function_table. It should always be linker synthesized with the final output executable. Differential Revision: https://reviews.llvm.org/D94993
-
Richard Smith authored
if E is merely instantiation-dependent." This change leaves us unable to distinguish between different function templates that differ in only instantiation-dependent ways, for example template<typename T> decltype(int(T())) f(); template<typename T> decltype(int(T(0))) f(); We'll need substantially better support for types that are instantiation-dependent but not dependent before we can go ahead with this change. This reverts commit e3065ce2.
-
Richard Smith authored
argument's value off it during substitution.
-
Siva Chandra authored
This change does not try to move the common parts of x86 and aarch64 and build few abstractions over them. While this is possible, x86 story needs a bit of cleanup, especially around manipulation of the mxcsr register. Moreover, on x86 one can raise exceptions without performing exception raising operations. So, all of this can be done in follow up patches. Reviewed By: lntue Differential Revision: https://reviews.llvm.org/D94947
-
Alexey Bataev authored
OMP_MAP_TARGET_PARAM flag is used to mark the data that shoud be passed as arguments to the target kernels, nothing else. But the compiler still marks the data with OMP_MAP_TARGET_PARAM flags even if the data is passed to the data movement directives, like target data, target update etc. This flag is just ignored for this directives and the compiler does not need to emit it. Reviewed By: cchen Differential Revision: https://reviews.llvm.org/D91261
-
Arthur Eubanks authored
In preparation for turning on opt's -enable-new-pm by default, this pins uses of passes via the legacy "opt -passname" with pass names beginning with "polly-" and "polyhedral-info" to the legacy PM. Many of these tests use -analyze, which isn't supported in the new PM. (This doesn't affect uses of "opt -passes=passname"). rL240766 accidentally removed `-polly-prepare` in phi_not_grouped_at_top.ll, and it also doesn't use the output of -analyze. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D94266
-
Mircea Trofin authored
Differential Revision: https://reviews.llvm.org/D94853
-
Alexey Bataev authored
This reverts commit 438682de to fix the bug with the reducing size of the resulting vector for the entry node with multiple users.
-
Jeroen Dobbelaere authored
D75825 and D75828 modified llvm/test/Transforms/Inline/noalias2.ll to handle llvm.assume. The checking though was broken. The NO_ASSUME has been replaced by a normal CHECK; the ASSUME rules were never triggered and have been removed. The test checks have been regenerated. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D94978
-
Mitch Phillips authored
This reverts commit 6529d7c5. Reason: Broke the ASan buildbots. http://lab.llvm.org:8011/#/builders/99/builds/1567
-
peter klausler authored
The utility routine WhyNotModifiable() needed to become more aware of the use of pointers in data-refs; the targets of pointer components are sometimes modifiable even when the leftmost ("base") symbol of a data-ref is not. Added a new unit test for WhyNotModifiable() that uses internal READ statements (mostly), since I/O semantic checking uses WhyNotModifiable() for all its definability checking. Differential Revision: https://reviews.llvm.org/D94849 -
Fangrui Song authored
R_PPC64_ADDR16_HI represents bits 16-31 of a 32-bit value R_PPC64_ADDR16_HIGH represents bits 16-31 of a 64-bit value. In the Linux kernel, `LOAD_REG_IMMEDIATE_SYM` defined in `arch/powerpc/include/asm/ppc_asm.h` uses @l, @high, @higher, @highest to load the 64-bit value of a symbol. Fixes https://github.com/ClangBuiltLinux/linux/issues/1260
-
Fangrui Song authored
There are no tests for REL16_* and TPREL16_*.
-
Fangrui Song authored
-
Jonas Devlieghere authored
Use a mutex to protect concurrent access to the signpost map. This fixes nondeterministic crashes in LLDB that appeared after using signposts in the timer implementation. Differential revision: https://reviews.llvm.org/D94285
-
Wim Leflere authored
C++23 string contains implementation and tests Paper: https://wg21.link/P1679R3 Standard (string): https://eel.is/c++draft/string.contains Standard (string_view): https://eel.is/c++draft/string.view.ops#lib:contains,basic_string_view Differential Revision: https://reviews.llvm.org/D93912
-
Mariya Podchishchaeva authored
The pass has dependency on 'TargetTransformInfoWrapperPass', but the corresponding call to INITIALIZE_PASS_DEPENDENCY was missing. Differential Revision: https://reviews.llvm.org/D94916
-
Nikita Popov authored
Relative to the original change, this adds a check that the instruction on which we're replacing operands is safe to speculatively execute, because that's what we're effectively doing. We're executing the instruction with the replaced operand, which is fine if it's pure, but not fine if can cause side-effects or UB (aka is not speculatable). Additionally, we cannot (generally) replace operands in phi nodes, as these may refer to a different loop iteration. This is also covered by the speculation check. ----- InstCombine already performs a fold where X == Y ? f(X) : Z is transformed to X == Y ? f(Y) : Z if f(Y) simplifies. However, if f(X) only has one use, then we can always directly replace the use inside the instruction. To actually be profitable, limit it to the case where Y is a non-expr constant. This could be further extended to replace uses further up a one-use instruction chain, but for now this only looks one level up. Among other things, this also subsumes D94860. Differential Revision: https://reviews.llvm.org/D94862
-
Nikita Popov authored
In particular, add tests for speculatable and non-speculatable instructions.
-
Arthur Eubanks authored
This follows a similar ELF change. Reviewed By: MaskRay, sbc100 Differential Revision: https://reviews.llvm.org/D93253
-
Craig Topper authored
[RISCV] Add DAG combine to turn (setcc X, 1, setne) -> (setcc X, 0, seteq) if we can prove X is 0/1. If we are able to compare with 0 instead of 1, we might be able to fold the setcc into a beqz/bnez. Often these setccs start life as an xor that gets converted to a setcc by DAG combiner's rebuildSetcc. I looked into a detecting (xor X, 1) and converting to (seteq X, 0) based on boolean contents being 0/1 in rebuildSetcc instead of using computeKnownBits. It was very perturbing to AMDGPU tests which I didn't look closely at. It had a few changes on a couple other targets, but didn't seem to be much if any improvement. Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D94730
-
Shilei Tian authored
[Clang][OpenMP] Fixed an issue that clang crashed when compiling OpenMP program in device only mode without host IR D94745 rewrites the `deviceRTLs` using OpenMP and compiles it by directly calling the device compilation. `clang` crashes because entry in `OffloadEntriesDeviceGlobalVar` is unintialized. Current design supposes the device compilation can only be invoked after host compilation with the host IR such that `clang` can initialize `OffloadEntriesDeviceGlobalVar` from host IR. This avoids us using device compilation directly, especially when we only have code wrapped into `declare target` which are all device code. The same issue also exists for `OffloadEntriesInfoManager`. In this patch, we simply initialized an entry if it is not in the maps. Not sure we need an option to tell the device compiler that it is invoked standalone. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D94871
-
Louis Dionne authored
Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
-
Louis Dionne authored
When the Debug mode is enabled, we disable extern declarations because we don't want to use the functions compiled in the library, which might not have had the debug mode enabled when built. However, some extern declarations need to be kept, because code correctness depends on it. 31e82037 removed those declarations, which had the unintended consequence of breaking the debug build. This commit fixes that by re-introducing a separate macro for the required extern declarations, and adds a comment so that we don't fall into that trap in the future. Differential Revision: https://reviews.llvm.org/D94718
-
Reid Kleckner authored
These checks help find llvm.org/pr48582 without ASan
-
Reid Kleckner authored
Helped me reduce llvm.org/pr48582
-
Jeroen Dobbelaere authored
Just like llvm.assume, there are a lot of cases where we can just ignore llvm.experimental.noalias.scope.decl. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D93042
-
Richard Smith authored
-
Brendon Cahoon authored
The Hexagon Vector Combine pass genertes stores for a complete aligned vector. The start of each section is a multiple of the vector size, so that value is passed to normalize to compute the offset of the stores in the section. The first store may not occur at offset 0 when there is a gap between sections.
-
Utkarsh Saxena authored
Differential Revision: https://reviews.llvm.org/D94927
-
Jay Foad authored
Rename the *_gfx9_gfx10 ttmp registers to *_gfx9plus for simplicity, and use the corresponding isGFX9Plus predicate to decide when to use them instead of the old *_vi versions. Differential Revision: https://reviews.llvm.org/D94975
-
Jessica Paquette authored
Windows buildbots were not happy with using find_if + instructionsWithoutDebug. In cfc60730, instructionsWithoutDebug is not technically necessary. So, just iterate over the block directly. http://lab.llvm.org:8011/#/builders/127/builds/4732/steps/7/logs/stdio
-
Jessica Paquette authored
This is a restricted version of the combine in `DAGCombiner::MatchLoadCombine`. (See D27861) This tries to recognize patterns like below (assuming a little-endian target): ``` s8* x = ... s32 val = a[0] | (a[1] << 8) | (a[2] << 16) | (a[3] << 24) -> s32 val = *((i32)a) s8* x = ... s32 val = a[3] | (a[2] << 8) | (a[1] << 16) | (a[0] << 24) -> s32 val = BSWAP(*((s32)a)) ``` (This patch also handles the big-endian target case as well, in which the first example above has a BSWAP, and the second example above does not.) To recognize the pattern, this searches from the last G_OR in the expression tree. E.g. ``` Reg Reg \ / OR_1 Reg \ / OR_2 \ Reg .. / Root ``` Each non-OR register in the tree is put in a list. Each register in the list is then checked to see if it's an appropriate load + shift logic. If every register is a load + potentially a shift, the combine checks if those loads + shifts, when OR'd together, are equivalent to a wide load (possibly with a BSWAP.) To simplify things, this patch (1) Only handles G_ZEXTLOADs (which appear to be the common case) (2) Only works in a single MachineBasicBlock (3) Only handles G_SHL as the bit twiddling to stick the small load into a specific location An IR example of this is here: https://godbolt.org/z/4sP9Pj (lifted from test/CodeGen/AArch64/load-combine.ll) At -Os on AArch64, this is a 0.5% code size improvement for CTMark/sqlite3, and a 0.4% improvement for CTMark/7zip-benchmark. Also fix a bug in `isPredecessor` which caused it to fail whenever `DefMI` was the first instruction in the block. Differential Revision: https://reviews.llvm.org/D94350 -
Fraser Cormack authored
Original patch by @rogfer01. This patch adds support for sign-, zero-, and any-extension from scalable mask vector types to integer vector types, as well as truncation in the opposite direction. Authored-by:
Roger Ferrer Ibanez <rofirrim@gmail.com> Co-Authored-by:
Fraser Cormack <fraser@codeplay.com> Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D94590
-
Abhina Sreeskantharajan authored
On z/OS, the error message "EDC5111I Permission denied." is not matched correctly in lit tests. This patch updates the check expression to match successfully. Differential Revision: https://reviews.llvm.org/D94432
-
Michael Kruse authored
This fixes llvm.org/PR48554 Some test cases had to be updated because the hash function for union_maps have been changed which affects the output order.
-
Raphael Isemann authored
This is mostly SEO so that the new API can take over the old API when people search for the different SB* classes. Sadly epydoc decided to throw in a -class prefix behind all the class file names, so we can't just overwrite the old files with the newly generated ones. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D94900
-
David Green authored
We have no lowering for VSELECT vXi1, vXi1, vXi1, so mark them as expanded to turn them into a series of logical operations. Differential Revision: https://reviews.llvm.org/D94946
-