- Oct 22, 2020
-
-
Max Kazantsev authored
This better reflects what this logic actually does.
-
Max Kazantsev authored
This reverts commit 3fce5ea7. `make check` broken.
-
Sjoerd Meijer authored
This improves simplifications for pattern `icmp (X+Y), (X+Z)` -> `icmp Y,Z` if only one of the operands has NSW set, e.g.: icmp slt (x + 0), (x +nsw 1) We can still safely rewrite this to: icmp slt 0, 1 because we know that the LHS can't overflow if the RHS has NSW set and C1 < C2 && C1 >= 0, or C2 < C1 && C1 <= 0 This simplification is useful because ScalarEvolutionExpander which is used to generate code for SCEVs in different loop optimisers is not always able to put back NSW flags across control-flow, thus inhibiting CFG simplifications. Differential Revision: https://reviews.llvm.org/D89317 -
Fangrui Song authored
findNearestCommonDominator never returns nullptr.
-
Jonas Devlieghere authored
Make these types conform to the LLVM Coding Standards: > Type names (including classes, structs, enums, typedefs, etc) should > be nouns and start with an upper-case letter.
-
Alex Lorenz authored
target Apple Silicon macOS machines Differential Revision: https://reviews.llvm.org/D82699
-
Martin Storsjö authored
Implement the corresponding thing using windows functions as well. Differential Revision: https://reviews.llvm.org/D89864
-
Martin Storsjö authored
The individual enum values in copy_options and file_type aren't specified in the standard. The standard doesn't require fs::path::format to be a scoped enum. Differential Revision: https://reviews.llvm.org/D89866
-
Martin Storsjö authored
Differential Revision: https://reviews.llvm.org/D89867
-
Martin Storsjö authored
Copy over the compiler detection structure from libcxx, and set _LIBCXXABI_WEAK like _LIBCPP_WEAK is set in libcxx. This allows users to override operator new/delete, if using those operators from libcxxabi instead of from libcxx. Differential Revision: https://reviews.llvm.org/D89863
-
Tony authored
- Make the SIMemoryLegalizer insertAcquire function be in the same order for each target to be consistent. Differential Revision: https://reviews.llvm.org/D89880
-
Douglas Yung authored
A recent commit to revert llvm-symbolizer changes forgot to revert this test fix. This reverts commit 5e656ee4.
-
Arthur Eubanks authored
Many of these tests don't use the output of -analyze.
-
Serguei Katkov authored
Use BFI if it is available and BPI otherwise. This is a promised follow-up after D89541. Reviewers: ebrevnov, mkazantsev Reviewed By: ebrevnov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D89773
-
Arthur Eubanks authored
-
Vy Nguyen authored
Differential Revision: https://reviews.llvm.org/D89616
-
Arthur Eubanks authored
-analyze does not work with the NPM. 'print<foo>' passes should be used instead.
-
Richard Smith authored
-
Teresa Johnson authored
Split out of D89086 as suggested. Change the default of the log_path flag to nullptr, and the code consuming that flag (ReportFile::SetReportPath), to treat nullptr as stderr (so no change to the behavior of existing users). This allows code to distinguish between the log_path being specified explicitly as stderr vs the default. This is so the flag can be used to override the new report path variable that will be encoded in the binary for memprof for runtime testing. Differential Revision: https://reviews.llvm.org/D89629
-
Xiang1 Zhang authored
Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D88631
-
Arthur Eubanks authored
-
Chen Zheng authored
-
Richard Smith authored
account when determining the identity of a class NTTP.
-
Arthur Eubanks authored
-
Craig Topper authored
[FPEnv][X86][SystemZ] Use different algorithms for i64->double uint_to_fp under strictfp to avoid producing -0.0 when rounding toward negative infinity Some of our conversion algorithms produce -0.0 when converting unsigned i64 to double when the rounding mode is round toward negative. This switches them to other algorithms that don't have this problem. Since it is undefined behavior to change rounding mode with the non-strict nodes, this patch only changes the behavior for strict nodes. There are still problems with unsigned i32 conversions too which I'll try to fix in another patch. Fixes part of PR47393 Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D87115
-
Richard Smith authored
-
Vy Nguyen authored
Split off from D89251 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D89884
-
Zequan Wu authored
See discussion: https://reviews.llvm.org/D89590 This reverts commit cdd006ee.
-
Gaurav Jain authored
Differential Revision: https://reviews.llvm.org/D89858
-
David Blaikie authored
Seems users have enough different uses of the symbolizer where they might have unknown binaries and offsets such that "best effort" behavior is all that's expected of llvm-symbolizer - so even erroring on unknown executables and out of bounds offsets might not be suitable. This reverts commit 1de01997. This reverts commit a7b209a6. This reverts commit 338dd138.
-
Quentin Colombet authored
Prior to this patch, computeKnownBits would only try to deduce trailing zeros bits for getelementptrs. This patch adds the logic to treat geps as a series of add * scaling factor. Thanks to this patch, using a gep or performing an address computation directly "by hand" (ptrtoint followed by adds and mul followed by inttoptr) offers the same computeKnownBits information. Previously, the "by hand" approach would have given more information. This is related to https://llvm.org/PR47241. Differential Revision: https://reviews.llvm.org/D86364
-
Richard Smith authored
-
Louis Dionne authored
-
Louis Dionne authored
It's good to run the installation step to make sure it works properly, as build system changes can break that.
-
rdzhabarov authored
[mlir] Simplify DDR matching patterns with equal operands for operators where it's applicable. Added documentation. This https://reviews.llvm.org/D89254 diff introduced implicit matching between same name operands. Differential Revision: https://reviews.llvm.org/D89598
-
Felix Berger authored
Since its call operator is const but can modify the state of its underlying functor we cannot tell whether the copy is necessary or not. This avoids false positives. Reviewed-by: aaron.ballman, gribozavr2 Differential Revision: https://reviews.llvm.org/D89332
-
Richard Smith authored
This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
-
Joseph Huber authored
The changes made in D88594 caused the test OpenMP/driver.c to fail on a 32-bit host becuase it was offloading to a 64-bit architecture by default. The offloading test was moved to a new file and a feature was added to the lit config to check for a 64-bit host. Reviewed By: daltenty Differential Revision: https://reviews.llvm.org/D89904
-
Louis Dionne authored
This commit should really be named "Workaround external projects depending on libc++ build system implementation details". It seems that the compiler-rt build (and perhaps other projects) is relying on the fact that we copy libc++ and libc++abi headers to `<build-root>/include/c++/v1`. This was changed by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1` and broke the compiler-rt build. I'm committing this workaround to fix the compiler-rt build, but we should remove reliance on implementation details like that. The correct way to setup the compiler-rt build would be to "link" against the `cxx-headers` target in CMake, or to run `install-cxx-headers` using an appropriate installation prefix, and then manually add a `-I` path to that location.
-