- May 16, 2023
-
-
LLVM GN Syncbot authored
-
LLVM GN Syncbot authored
-
Mark de Wever authored
This was planned for LLVM 15 but was never done. Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D150580
-
Valentin Clement authored
Lower host_data construct to the acc.host_data operation. Depends on D150289 Reviewed By: razvanlupusoru, jeanPerier Differential Revision: https://reviews.llvm.org/D150290
-
Alexey Bataev authored
Prepare functions for generalization of codegen/cost estimation. Differential Revision: https://reviews.llvm.org/D150121
-
zijunzhao authored
-
Peter Smith authored
A code-review comment to change a couple of CHECK to CHECK-NEXT that I forgot to apply prior to committing. Differential Revision: https://reviews.llvm.org/D150445
-
Nikolas Klauser authored
This reverts commit b049fc04. The wrong patch was landed.
-
Aart Bik authored
Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D150172
-
Slava Zakharin authored
The temporary descriptor must be either Pointer or Allocatable, otherwise its memory will not be freed. Reviewed By: klausler Differential Revision: https://reviews.llvm.org/D150534
-
Slava Zakharin authored
Reviewed By: klausler Differential Revision: https://reviews.llvm.org/D150533
-
LLVM GN Syncbot authored
-
Louis Dionne authored
It was confusing to some contributors because it appeared in a prominent place on the Contibuting page.
-
Nikolas Klauser authored
Reviewed By: ldionne, #libc Spies: jloser, libcxx-commits Differential Revision: https://reviews.llvm.org/D149706
-
AdityaK authored
Bringing parity with aarch64-android https://github.com/google/android-riscv64/issues/9#issuecomment-1535454205 Reviewers: enh, danalbert, pirama, srhines Differential Revision: https://reviews.llvm.org/D150490
-
https://reviews.llvm.org/D150352Amy Kwan authored
This patch fixes the following build error on the clang-ppc64le-rhel bot seen in in https://lab.llvm.org/buildbot/#/builders/57/builds/26816/steps/5/logs/stdio: FAILED: tools/clang/tools/extra/clang-tidy/bugprone/CMakeFiles/obj.clangTidyBugproneModule.dir/UncheckedOptionalAccessCheck.cpp.o .../clang-ppc64le-rhel/llvm-project/clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp:43:27: error: 'build' is deprecated: Use the version that takes a const Decl & instead [-Werror,-Wdeprecated-declarations] ControlFlowContext::build(&FuncDecl, *FuncDecl.getBody(), ASTCtx); ^ .../ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h:41:3: note: 'build' has been explicitly marked deprecated here LLVM_DEPRECATED("Use the version that takes a const Decl & instead", "") ^ .../clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Compiler.h:143:50: note: expanded from macro 'LLVM_DEPRECATED' #define LLVM_DEPRECATED(MSG, FIX) __attribute__((deprecated(MSG, FIX))) ^ 1 error generated.
-
Sergei Barannikov authored
Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D150530
-
Vasileios Porpodas authored
This deprecates `vectorizeSimpleInstructions()` and replaces it with separate functions that vectorize CmpInsts and Inserts. Differential Revision: https://reviews.llvm.org/D149993
-
Kazu Hirata authored
This patch fixes: mlir/lib/Dialect/MemRef/Utils/MemRefUtils.cpp:45:2: error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
-
LLVM GN Syncbot authored
-
Nikolas Klauser authored
Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D149615
-
Sergei Barannikov authored
D150520 converted the test to use opaque pointers. The update version fails on PowerPC because of different return type of the function. This patch resolves the failure by removing the return type check; it also makes the test look more like it was before the conversion to prevent other potential issues caused by ABI differences across targets.
-
Qiongsi Wu authored
https://reviews.llvm.org/D144190 added a test case that is target dependent and requires assembly code generation, which fails on x64 and aarch64 buildbots. This patch removes the test case. We have test cases for code generation added in https://reviews.llvm.org/D144189 already and this removed case was nice to have. Differential Revision: https://reviews.llvm.org/D150586
-
Slava Zakharin authored
Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D150502
-
Slava Zakharin authored
Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D150501
-
Erich Keane authored
-
Jay Foad authored
This method is unused since MipsRegisterInfo is abstract and it is overridden in both concrete subclasses.
-
Joseph Huber authored
We do a lot of arithmetic on void pointers here, so include a helper and make some more consistent names. Changes no functionality. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D150576
-
Mateja Marjanovic authored
For image and buffer stores the default behaviour on GFX11 and older is to set all unset components to zero. So if we pass only X component it will be the same as X000, or XY same as XY00. This patch simplifies the passed vector of components in InstCombine by removing zero components from the end. For image stores it also trims DMask if necessary. Reviewed By: foad, arsenm Differential Revision: https://reviews.llvm.org/D146737
-
Dinar Temirbulatov authored
Currently any cast operation with fixed length vectors uses NEON costs, If those operations are end up using SVE instruction then we estimate those operations based upon SVE costs. Differential Revision: https://reviews.llvm.org/D133955
-
Kadir Cetinkaya authored
FunctionDecls can be created with null types (D124351 added such a new code path), to be filled in later. But parsing can stop before completing the Decl (e.g. if code completion point is reached). Unfortunately most of the methods in FunctionDecl and its derived classes assume a complete decl and don't perform null-checks. Since we're not encountring crashes in the wild along other code paths today introducing extra checks into quite a lot of places didn't feel right (due to extra complexity && run time checks). I believe another alternative would be to change Parser & Sema to never create decls with invalid types, but I can't really see an easy way of doing that, as most of the pieces are structured around filling that information as parsing proceeds. Differential Revision: https://reviews.llvm.org/D149733
-
- May 15, 2023
-
-
Erich Keane authored
Now that we've updated to C++23, we need to add C++26/C++2c command line flags, as discussed in https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383 Differential Revision: https://reviews.llvm.org/D150450
-
J. Ryan Stinnett authored
This reverts commit d421f522. LLDB tests are failing as shown in https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/55133/testReport/
-
Aart Bik authored
The sparse compiler now has two prototype strategies for GPU acceleration: * CUDA codegen: this converts sparsified code to CUDA threads * CUDA libgen: this converts pre-sparsified code to cuSPARSE library calls This revision introduces the first steps required for the second approach. Reviewed By: ThomasRaoux Differential Revision: https://reviews.llvm.org/D150170
-
Qiongsi Wu authored
This patch adds clang options `-mxcoff-roptr` and `-mno-xcoff-roptr` to specify storage locations for constant pointers on AIX. When the `-mxcoff-roptr` option is in effect, constant pointers, virtual function tables, and virtual type tables are placed in read-only storage. When the `-mno-xcoff-roptr` option is in effect, pointers, virtual function tables, and virtual type tables are placed are placed in read/write storage. This patch depends on https://reviews.llvm.org/D144189. Reviewed By: hubert.reinterpretcast, stephenpeckham Differential Revision: https://reviews.llvm.org/D144190
-
Jay Foad authored
-
Oleg Shyshkov authored
Differential Revision: https://reviews.llvm.org/D150543
-
Chenle Yu authored
This patch implements the "task record and replay" mechanism. The idea is to be able to store tasks and their dependencies in the runtime so that we do not pay the cost of task creation and dependency resolution for future executions. The objective is to improve fine-grained task performance, both for those from "omp task" and "taskloop". The entry point of the recording phase is __kmpc_start_record_task, and the end of record is triggered by __kmpc_end_record_task. Tasks encapsulated between a record start and a record end are saved, meaning that the runtime stores their dependencies and structures, referred to as TDG, in order to replay them in subsequent executions. In these TDG replays, we start the execution by scheduling all root tasks (tasks that do not have input dependencies), and there will be no involvement of a hash table to track the dependencies, yet tasks do not need to be created again. At the beginning of __kmpc_start_record_task, we must check if a TDG has already been recorded. If yes, the function returns 0 and starts to replay the TDG by calling __kmp_exec_tdg; if not, we start to record, and the function returns 1. An integer uniquely identifies TDGs. Currently, this identifier needs to be incremented manually in the source code. Still, depending on how this feature would eventually be used in the library, the caller function must do it; also, the caller function needs to implement a mechanism to skip the associated region, according to the return value of __kmpc_start_record_task. Reviewed By: tianshilei1992 Differential Revision: https://reviews.llvm.org/D146642
-
Nikita Popov authored
Align the way we perform exhaustive tests for KnownBits with what we do for ConstantRange. Test each case separately by specifying a function on KnownBits and one on APInts. Additionally, specify a callback that determines which cases are supposed to be optimal, rather than only correct. Unlike the ConstantRange case there is a well-defined, unique notion of optimality for KnownBits. If a failure occurs, print out the inputs, computed result and exact result. Adjust the printing function to produce the output in a format that is meaningful for KnownBits, i.e. print the actual known bits, using ? to signify unknowns and ! to signify conflicts.
-