This patch renames DPLabel to DbgLabelRecord, in accordance with the
ongoing DbgRecord rename. This rename was fairly trivial, since DPLabel
isn't as widely used as DPValue and has no real conflicts in either its
full or abbreviated name. As usual, the entire replacement was done
automatically, with `s/DPLabel/DbgLabelRecord/` and `s/DPL/DLR/`.
Adds improved bitwidth analysis for shl/ashr/lshr instructions. The
analysis is based on similar version in InstCombiner.
Reviewers: RKSimon
Reviewed By: RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/84356
The instruction itself can be considered good for minbitwidth casting,
even if one of the operand checks returns false.
Reviewers: RKSimon
Reviewed By: RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/84363
This PR changes the build system to use use the sources for the module
`omp_lib` and the `omp_lib.h` include file from the `openmp` runtime
project and not from a separate copy of these files. This will greatly
reduce potential for inconsistencies when adding features to the OpenMP
runtime implementation.
When the OpenMP subproject is not configured, this PR also disables the
corresponding LIT tests with a "REQUIRES" directive at the beginning of
the OpenMP test files.
---------
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
The -Wcast-fuction-type-strict has been moved under dignstic group
-Wextra.
Edited the test cases for -Wcast-fuction-type-strict and
-Wcast-fuction-type in Sema an SemaCXX.
Added a new test case which include a functionality that was already in
the -Wextra group, i.e -Wignored-qualifiers with
-Wcast-fuction-type-strict.
Fixes: #76872
This has been tested with arrays with compile-time constant bounds.
Allocatable arrays and arrays with non-constant bounds are not yet
supported. User-defined reduction functions are also not yet supported.
The design is intended to work for arrays with non-constant bounds too
without a lot of extra work (mostly there are bugs in OpenMPIRBuilder I
haven't fixed yet).
We need some way to get these runtime bounds into the reduction init and
combiner regions. To keep things simple for now I opted to always box
the array arguments so the box can be passed as one argument and the
lower bounds and extents read from the box. This has the disadvantage of
resulting in fir.box_dim operations inside of the critical section. If
these prove to be a performance issue, we could follow OpenACC reading
box lower bounds and extents before the reduction and passing them as
block arguments to the reduction init and combiner regions. I would
prefer to keep things simple for now.
Note: this implementation only works when the HLFIR lowering is used. I
don't think it is worth supporting FIR-only lowering because the plan is
for that to be removed soon.
OpenMP array reductions 6/6
Previous PR: https://github.com/llvm/llvm-project/pull/84957
These were disabled due to ODR violations with mixed versions of
clang-tidy and the clang libraries. This issue was fixed in
e19e8600cf743690e1a23fb8a2b0dfbe2dafe559.
This reverts commit 0bbada93a559b604797fe57978f3eca5e41edaeb.
Adds a second parameter (default to 0) to isLegalAddImmediate, to
represent a scalable immediate.
Extends the AArch64 implementation to match immediates based on what addvl and inc[h|w|d] support.
Reverts llvm/llvm-project#84405
In between of passing the precommit tests on github and being merged
some change (perhaps in the AArch64 backend?) landed which resulted
in altering the generated resolver. I will regenerate the tests
perhaps using a less sensitive runline to such changes.
This fixes the following failure when doing a clean build (in particular
no .ninja* lying around) of lib/libMLIRSPIRVDialect.a only:
```
mlir/lib/Dialect/SPIRV/IR/SPIRVDialect.cpp:17:
mlir/include/mlir/Dialect/GPU/IR/CompilationInterfaces.h:120:10: fatal error: mlir/Dialect/GPU/IR/CompilationAttrInterfaces.h.inc: No such file or directory
```
This fixes the following failure when doing a clean build (in particular
no .ninja* lying around) of lib/libMLIRAffineAnalysis.a only:
In file included from
mlir/lib/Dialect/Affine/Analysis/AffineAnalysis.cpp:20:
mlir/include/mlir/Dialect/Func/IR/FuncOps.h:29:10: fatal error:
mlir/Dialect/Func/IR/FuncOps.h.inc: No such file or directory
- Give the tablegen record for the Real the same name as the tablegen
record for the pseudo. This removes all cases where the same
instruction name has to be mentioned more than once on the definition
line.
- Use multiclasses for all Real definitions, to allow suffixes to be
added bit by bit, e.g. first _SADDR and then _gfx11.
This is a similar approach to the one used in BUFInstructions.td.
As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the representation of the `inrange` attribute, which
is used for vtable splitting.
Currently, inrange is specified as follows:
```
getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 1, i64 2)
```
The `inrange` is placed on a GEP index, and all accesses must be "in
range" of that index. The new representation is as follows:
```
getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, i32 1, i64 2)
```
This specifies which offsets are "in range" of the GEP result. The new
representation will continue working when canonicalizing to ptradd
representation:
```
getelementptr inbounds inrange(-16, 16) (i8, ptr @vt, i64 48)
```
The inrange offsets are relative to the return value of the GEP. An
alternative design could make them relative to the source pointer
instead. The result-relative format was chosen on the off-chance that we
want to extend support to non-constant GEPs in the future, in which case
this variant is more expressive.
This implementation "upgrades" the old inrange representation in bitcode
by simply dropping it. This is a very niche feature, and I don't think
trying to upgrade it is worthwhile. Let me know if you disagree.
OpenMP reduction declare operations can contain FIR code which needs to
be lowered to LLVM. With array reductions, these regions can contain
more complicated operations which need PreCGRewriting. A similar extra
case was already needed for fir::GlobalOp.
OpenMP array reductions 3/6
Previous PR: https://github.com/llvm/llvm-project/pull/84953
Next PR: https://github.com/llvm/llvm-project/pull/84955
Most FIR passes only look for FIR operations inside of functions (either
because they run only on func.func or they run on the module but iterate
over functions internally). But there can also be FIR operations inside
of fir.global, some OpenMP and OpenACC container operations.
This has worked so far for fir.global and OpenMP reductions because they
only contained very simple FIR code which doesn't need most passes to be
lowered into LLVM IR. I am not sure how OpenACC works.
In the long run, I hope to see a more systematic approach to making sure
that every pass runs on all of these container operations. I will write
an RFC for this soon.
In the meantime, this pass duplicates the CFG conversion pass to also
run on omp reduction operations. This is similar to how the
AbstractResult pass is already duplicated for fir.global operations.
OpenMP array reductions 2/6
Previous PR: https://github.com/llvm/llvm-project/pull/84952
Next PR: https://github.com/llvm/llvm-project/pull/84954
---------
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
This fixes the following failure when doing a clean build (in particular
no .ninja* lying around) of lib/libMLIRLinalgToStandard.a only:
```
In file included from mlir/include/mlir/Dialect/Vector/Transforms/VectorTransforms.h:12,
from mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h:21,
from mlir/lib/Conversion/LinalgToStandard/LinalgToStandard.cpp:15:
mlir/include/mlir/Dialect/Vector/Transforms/VectorRewritePatterns.h:20:10: fatal error: mlir/Dialect/Vector/Transforms/VectorTransformsEnums.h.inc: No such file or directory
```
We would like the resolver to be generated eagerly, even if the
versioned function is not called from the current translation
unit. Fixes#81494. It further allows Multi Versioning to work
even if the default target version attribute is omitted from
function declarations.
## Abstract
This pull request removes the `__workaround_52970` concept. This concept
is a workaround for a bug described in #52970, which causes the compiler
to trigger ADL on a pointer to an incomplete type in an SFINAE context.
This bug is fixed in Clang 14.
## Reference
- [[clang] Don't typo-fix an expression in a SFINAE
context](https://reviews.llvm.org/D117603)
- [[libc++] [ranges] ADL-proof the [range.access]
CPOs.](https://reviews.llvm.org/D116239)
## Abstract
This pull request implements LWG3715: `view_interface::empty` is
overconstrained. Here is an example similar to those described in the
report, which compiles with `-stdlib=libstdc++` but failed to compile
with `-stdlib=libc++`:
```cpp
// https://godbolt.org/z/EWEoTzah3
std::istringstream input("1 2 3 4 5");
auto i = std::views::istream<int>(input);
auto r = std::views::counted(i.begin(), 4) | std::views::take(2);
assert(!r.empty());
```
## Reference
- [Draft C++ Standard:
[view.interface.general]](https://eel.is/c++draft/view.interface.general)
- [LWG3715](https://wg21.link/LWG3715)
In other contexts, install directories such as
LIBCXX_INSTALL_LIBRARY_DIR and LIBCXX_INSTALL_MODULES_DIR can be
specified either as a relative path, relative to CMAKE_INSTALL_PREFIX,
or as an absolute path.
When calculating the relative path between the two, account for the fact
that LIBCXX_INSTALL_MODULES_DIR and LIBCXX_INSTALL_LIBRARY_DIR can be
absolute paths too.
