- Sep 22, 2022
-
-
Congzhe Cao authored
This is a bugfix patch that resolves the following two bugs in loop interchange: 1. PR57148 which is an assertion error due to of loss of LCSSA form after interchange, as referred to test1() in pr57148.ll. 2. Use before def for the outermost loop induction variables after interchange, as referred to test2() in pr57148.ll. The fix in this patch is that: 1. In cases where the LCSSA form is not maintained after interchange, we update the IR to the LCSSA form again. 2. We split the phi nodes in the inner loop header into a separate basic block to avoid the situation where use of the outer indvar appears before its def after interchange. Previously we already did this for innermost loops, now we do it for non-innermost loops (e.g., middle loops) as well. Reviewed By: bmahjour, Meinersbur, #loopoptwg Differential Revision: https://reviews.llvm.org/D132055
-
Fanchen Kong authored
Use load32_zero instead of load32_splat to load the low 32 bits from memory to v128. Test cases are added to cover this change. Reviewed By: tlively Differential Revision: https://reviews.llvm.org/D134257
-
Congzhe Cao authored
This patch is to resolve the bug reported and discussed in https://reviews.llvm.org/D124926#3718761 and https://reviews.llvm.org/D124926#3719876. The problem is that loop interchange is a loopnest pass under the new pass manager, but the loop nest may not be constructed correctly by the loop pass manager after running loop interchange and before running the next pass, which might cause problems when it continues running the next pass. The reason that the loop nest is constructed incorrectly is that the outermost loop might have changed after interchange, and what was the original outermost loop is not the current outermost loop anymore. Constructing the loop nest based on the original outermost loop would generate an invalid loop nest. The fix in this patch is that, in the loop pass manager before running each loopnest pass, we re-cosntruct the loop nest based on the current outermost loop, if LPMUpdater notifies the loop pass manager that the previous loop nest has been invalidated by passes like loop interchange. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D132199
-
LiaoChunyu authored
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D134164
-
Chuanqi Xu authored
implement the option2 of P2014R0 This implements the option2 of https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2014r0.pdf. This also fixes https://github.com/llvm/llvm-project/issues/56671. Although wg21 didn't get consensus for the direction of the problem, we're happy to have some implementation and user experience first. And from issue56671, the option2 should be the pursued one. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D133341
-
Corentin Jabot authored
Unicode 15.0 adds 4,489 characters, for a total of 149,186 characters. These additions include 2 new scripts along with 20 new emoji characters, and 4,193 CJK ideographs. This changes modify most existing tables including - XID_Start/XID_Continue in Clang - The character name database (used by \N{} in Clang) - The list of formattable/printable codepoints - The case folding algorithm (which we had not updated since Unicode 9) - The list of nonspacing/enclosing marks used by the column width computation algorithm. The rest of the column width algorithm is not updated. Reviewed By: tahonermann Differential Revision: https://reviews.llvm.org/D133807 -
Craig Topper authored
Specifically predicates for extensions that are subsets of other extensions. These predicates should never be used. Should always check the superset extension or the superset ORed with the sub extendsion.
-
River Riddle authored
This allows for incrementally updating the old API usages without needing to update everything at once. PDL will be left on Both for a little bit and then flipped to prefixed when all APIs have been updated. Differential Revision: https://reviews.llvm.org/D134387
-
River Riddle authored
This allows for incrementally updating the old API usages without needing to update everything at once. These will be left on Both for a little bit and then flipped to prefixed when all APIs have been updated. Differential Revision: https://reviews.llvm.org/D134386
-
Jan Korous authored
showBRParamDiagnostics assumed stores happen only via function parameters while that can also happen via implicit parameters like 'self' or 'this'. The regression test caused a failed assert in the original cast to ParmVarDecl. Differential Revision: https://reviews.llvm.org/D133815
-
Vitaly Buka authored
Instrumentation just ORs shadow of inputs. I assume some result shadow bits can be reset if we go into specifics of particular checks, but as-is it is still an improvement against existing default strict instruction handler, when every set bit of input shadow is reported as an error. Reviewed By: kda Differential Revision: https://reviews.llvm.org/D134123
-
Craig Topper authored
-
Craig Topper authored
-
Fangrui Song authored
CWD may be read-only in some testing environments.
-
Katherine Rasmussen authored
Write a semantics test for the atomic intrinsic subroutine, atomic_xor. Reviewed By: rouson Differential Revision: https://reviews.llvm.org/D134298
-
Chris Bieneman authored
We have namespaces `DXIL` and `dxil`, which is just confusing. This renames `DXIL` -> `dxil` making everything consistent. While the LLVM coding standards don't have a clear direction here, I chose lower case because by my current unscientific count there are more places where we had the lowercase namespace than the uppercase.
-
Michael Wyman authored
When `objc_direct` methods were implemented, the implicit `_cmd` parameter was left as an argument to the method implementation function, but was unset by callers; if the method body referenced the `_cmd` variable, a selector load would be emitted inside the body. However, this leaves an unused argument in the ABI, and is unnecessary. This change removes the empty/unset argument, and if `_cmd` is referenced inside an `objc_direct` method it will emit local storage for the implicit variable. From the ABI perspective, `objc_direct` methods will have the implicit `self` parameter, immediately followed by whatever explicit arguments are defined on the method, rather than having one unset/undefined register in the middle. Differential Revision: https://reviews.llvm.org/D131424
-
Craig Topper authored
Name them after the instructions VFCVT_RTZ_X(U)_F_VL to make it clear that the ISD nodes don't have the poison semantics of ISD::SINT_TO_FP/UINT_TO_FP. I play to reuse this node for a FP_TO_SINT_SAT/FP_TO_UINT_SAT patch and need the instruction semantics.
-
Vitaly Buka authored
Removed FIXME which looks irrelevant. The error message happens only without -mattr=+avx. E.g. GOOD: opt llvm/test/Instrumentation/MemorySanitizer/avx-intrinsics-x86.ll -passes=msan -o - | llc -O3 -o /dev/null -mattr=+avx BAD: opt llvm/test/Instrumentation/MemorySanitizer/avx-intrinsics-x86.ll -passes=msan -o - | llc -O3 -o /dev/null So nothing to fix here. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D134119
-
Ivan Radanov Ivanov authored
-
Ivan Radanov Ivanov authored
Differential Revision: https://reviews.llvm.org/D134153
-
Kazu Hirata authored
Once we create an instance of InlineCost, we don't change its contents. Differential Revision: https://reviews.llvm.org/D134388
-
Philip Reames authored
We were recognizing vectors of floats, but not scalars. That's a tad odd.
-
Vitaly Buka authored
-
Fangrui Song authored
[Hexagon] Fix -Wunused-variable in non-assertion builds after f6e7ad56
-
Florian Mayer authored
Tested with the following program: ``` static volatile int* x = nullptr; void throws() __attribute__((noinline)) { if (getpid() == 0) return; throw "error"; } void maybe_throws() __attribute__((noinline)) { volatile int y = 1; x = &y; throws(); y = 2; } int main(int argc, char** argv) { int y; try { maybe_throws(); } catch (const char* e) { //printf("Caught\n"); } y = *x; printf("%d\n", y); // should be MTE failure. return 0; } ``` Built using `clang++ -c -O2 -target aarch64-linux -fexceptions -march=armv8-a+memtag -fsanitize=memtag-heap,memtag-stack` Currently only Android implements runtime support for MTE stack tagging. Without this change, we crash on `__cxa_get_globals` when trying to catch the exception (because the stack frame __cxa_get_globals frame will fail due to tags left behind on the stack). With this change, we crash on the `y = *x;` as expected, because the stack frame has been untagged, but the point... -
Fangrui Song authored
This option specifies a GCC installation directory such as /usr/lib/gcc/x86_64-linux-gnu/12, /usr/lib/gcc/x86_64-gentoo-linux-musl/11.2.0 . It is intended to replace --gcc-toolchain=, which specifies a directory where `lib/gcc{,-cross}` can be found. When --gcc-toolchain= is specified, the selected `lib/gcc/$triple/$version` installation uses complex logic and the largest GCC version is picked. There is no way to specify another version in the presence of multiple GCC versions. D25661 added gcc-config detection for Gentoo: `ScanGentooConfigs`. The implementation may be simplified by using --gcc-install-dir=. Reviewed By: mgorny Differential Revision: https://reviews.llvm.org/D133329 -
Fangrui Song authored
-
Jay Foad authored
This validation was introduced in D34003 for v_qsad/v_mqsad instructions but it applies to all instructions with earlyclobber operands, which now includes v_mad_i64/v_mad_u64. In all these cases I do not think there is documentation saying that the destination must not overlap the sources. Rather there are *some* cases where the instruction may not function correctly if there is an overlap, and we are using earlyclobber as a conservative way of preventing codegen from generating those cases. I think it is unhelpful for the assembler to enforce the earlyclobber restriction because it prevents assembling cases where the programmer knows that in fact the overlap is safe. See also: https://github.com/llvm/llvm-project/issues/57610 Differential Revision: https://reviews.llvm.org/D134272
-
Amara Emerson authored
I don't know what was going on originally with these tests. It seems reasonable to have the immediate be the same byte alignment unit as the IR, in which case we need to take the log2 in order to set the right number of low bits. This fixes a miscompile in chromium. Differential Revision: https://reviews.llvm.org/D134380
-
owenca authored
Also add a .clang-format file to clang/include/clang/Format and clang/unittests/Format to keep the directories formatted.
-
Leonard Chan authored
This reverts commit 411020ad. One of the tests here fails on some upstream builders: https://lab.llvm.org/buildbot#builders/16/builds/35314
-
Evgeny Shulgin authored
Direct continuation of https://reviews.llvm.org/D133887 Reviewed By: #clang-language-wg, aaron.ballman Differential Revision: https://reviews.llvm.org/D134207
-
Aaron Ballman authored
-
Leonard Chan authored
See https://github.com/llvm/llvm-project/issues/57815. dso_local_equivalent would fail with an assertion on forward-referenced globals. This is an issue that only comes up in textual IR, which is why we've never seen this assertion with clang. Differential Revision: https://reviews.llvm.org/D134234
-
Xiang Li authored
Lib profile could include all kind of entry functions. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D134326
-
Sanjay Patel authored
`(A * -2**C) + B --> B - (A << C)` https://alive2.llvm.org/ce/z/A6BWkf This inverts what Negator was doing before: D134310 / 0f32a5de Analysis and codegen are generally better without multiply, so we should favor this form even if we trade add for sub (because those are generally equivalent cost operations).
-
owenca authored
Fix braces and add .clang-format to keep the directory formatted. Differential Revision: https://reviews.llvm.org/D134329
-
Aaron Ballman authored
This code was added in b65b1f32, but it was not noticed that the [[fallthrough]] behavior was very wrong. In C mode, we would set the ParenExprType to CompoundLiteral and then promptly overwrite that information by falling through. After some investigation, I convinced myself that it is not possible to hit this code path in C, only in C++. I've switched it to be an assertion; I don't expect to hit it, but if we do hit it, that will at least give us a code example we can use to reason about the intent of the original code.
-
Fangrui Song authored
-