Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME
mechanism. It will only become active when
`LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the
`FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not
conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is
passed, nothing changes with the current build process.
Motivation:
* Consistency with LLVM's other runtime libraries (compiler-rt, libc,
libcxx, openmp offload, ...)
* Allows compiling the runtime for multiple targets at once using the
LLVM_RUNTIME_TARGETS configuration options
* Installs the runtime into the compiler's per-target resource directory
so it can be automatically found even when cross-compiling
Also see RFC discussion at
https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
The MRC format is
MRC GPRwithAPSR:$Rt, p_imm:$cop, imm0_7:$opc1,
c_imm:$CRn, c_imm:$CRm, 0, pred:$p
The $cop is the second operand.
Patch for
b7d41a11cd.
Introduce a subset of floating point classification ops to the Math
dialect. These ops mirror functions provided by the C math library and,
similarly to the existing `math.copysign`, belong to the math dialect.
Add a lowering of those ops to Nvidia libdevice calls when possible as
the first mechanism to exercise them.
It was clearly a typo regarding whether the array index expression has changed in its transforming.
This doesn't appear to be a functional change in practice, so no test case or release note provided.
Fixes#126113
There seems to be multiple declarations of __libcpp_verbose_abort, some
with noexcept and some without. Reverting to the previous
forward-declaration (without noexcept) which seemes to have worked
before.
Mostly mechanical changes in preparation of extracting the Flang-RT
"subproject" in #110217. This PR intends to only move pre-existing files
to the new folder structure, with no behavioral change. Common files
(headers, testing, cmake) shared by Flang-RT and Flang remain in
`flang/`.
Some cosmetic changes and files paths were necessary:
* Relative paths to the new path for the source files and
`add_subdirectory`.
* Add the new location's include directory to `include_directories`
* The unittest/Evaluate directory has unitests for flang-rt and Flang. A
new `CMakeLists.txt` was introduced for the flang-rt tests.
* Change the `#include` paths relative to the include directive
* clang-format on the `#include` directives
* Since the paths are part if the copyright header and include guards, a
script was used to canonicalize those
* `test/Runtime` and runtime tests in `test/Driver` are moved, but the
lit.cfg.py mechanism to execute the will only be added in #110217.
Fix `add_libclc_builtin_set` to add an appropriate dependency to either
`clspv-generate_convert.cl` or `generate_convert.cl` based on the `ARCH`
argument, rather than to both unconditionally. This fixes build failures
due to missing dependencies when `clspv*` targets are not enabled.
The added check mirrors the one from `libclc/CMakeLists.txt`.
Fixes: #127378
Asan reports it after #124103.
It's know case of false positive for Asan.
https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco#false-positives
It's can be avoided with `constexpr` constructors.
In general order global constructors in different
modules is undefined. If global constructor uses
external global, they can be not constructed yet.
However, implementation may contain workaround for
that, or the state of non-constructed global can
be still valid.
Asan will still falsely report such cases, as it
has no machinery to detect correctness of such
cases.
We need to fix/workaround the issue in libc++, as
it will affect many libc++ with Asan users.
Macros starting with alphabetic characters such as "LLVM" are in
the application name space and cannot be defined or used by a
conforming implementation's headers. This fixes the headers that
are entirely generated, and the __llvm-libc-common.h header to
use a conforming macro name for the header guard. That is, it
starts with "_LLVM_LIBC_" instead of "LLVM_LIBC_", as identifiers
starting with an underscore followed by a capital letter are in
the name space reserved for the implementation.
The remaining headers either will be fixed implicitly by removal
of their custom template files, or will need to be fixed by hand.
This updates the generated stdlib.h and malloc.h headers to
include the subsets of extenion functions declared by glibc that
are also supported by Scudo and that use only simple types.
Scudo's extensions not declared by glibc are omitted. glibc's
extensions not implemented by Scudo are omitted. The mallinfo
and mallinfo2 functions are omitted (at least for now) since they
need struct definitions for their return types.
Introduce lowering from arith.minnum/maxxnum operations to the
corresponding Nvidia libdevice calls. This requires to reorder pattern
population methods so that the libdevice-targeting patterns are
prioritized over default patterns targeting LLVM IR intrinsics from the
Arith dialect. The tests are placed into a separate file as the existing
gpu-to-nvvm.mlir files has a mode that forces Arith dialect operations
to be preserved as is without using a separate FileCheck tag to
differentiate.
Co-authored-by: William Moses <gh@wsmoses.com>
Create a IR BB directly for the middle.block, instead of creating the IR
BB during skeleton creation and then replacing the middle VPBB with a
VPIRBB.
This moves another part of skeleton creation to VPlan and simplififes
the code slightly by removing code to disconnect the middle block and
vector preheader + the corresponding DT update.
NFC modulo IR block naming and block creation order, which changes the
IR names for the blocks.
1. Documents `ConvertVectorStore`. As the generated output is rather complex, I
have refined the comments + variable names in:
* "vector-emulate-narrow-type-unaligned-non-atomic.mlir",
to serve as reference for this pattern.
2. As a follow-on for #123527, renames `isAlignedEmulation` to `isFullyAligned`
and `numSrcElemsPerDest` to `emulatedPerContainerElem`.
Currently, when `GreedyPatternRewriteDriver` fails, the log output
contains nested failure messages:
```bash
} -> failure : pattern failed to match
} -> failure : pattern failed to match
```
This may seem redundant, but these messages refer to different aspects
of the pattern application logic. This patch clarifies the distinction
by separately logging:
* Success/failure for a specific pattern (e.g., "_this pattern_ failed
to match on the Op currently being processed").
* Success/failure for an operation as a whole (e.g., "_all patterns_
failed to match the Op currently being processed").
Before (example with success):
```bash
Processing operation : (...) {
* Pattern (...) -> ()' {
Trying to match "..."
** Match Failure : (...)
} -> failure : pattern failed to match
* Pattern (...) -> ()' {
Trying to match "..."
} -> success : pattern applied successfully
} -> success : pattern matched
```
After (example with success):
```bash
Processing operation : (...) {
* Pattern (...) -> ()' {
Trying to match "..."
** Match Failure : (...)
} -> failure : pattern failed to match
* Pattern (...) -> ()' {
Trying to match "..."
} -> success : pattern applied successfully
} -> success : at least one pattern matched
```
This improves log clarity, making it easier to distinguish pattern-level
failures from operation-level outcomes.
This PR implements HLSL's initialization list behvaior as specified in
the draft language specifcation under
[*Decl.Init.Agg*](https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Decl.Init.Agg).
This behavior is a bit unusual for C/C++ because intermediate braces in
initializer lists are ignored and a whole array of additional
conversions occur unintuitively to how initializaiton works in C.
The implementaiton in this PR generates a valid C/C++ initialization
list AST for the HLSL initializer so that there are no changes required
to Clang's CodeGen to support this. This design will also allow us to
use Clang's rewrite to convert HLSL initializers to valid C/C++
initializers that are equivalent. It does have the downside that it will
generate often redundant accesses during codegen. The IR optimizer is
extremely good at eliminating those so this will have no impact on the
final executable performance.
There is some opportunity for optimizing the initializer list generation
that we could consider in subsequent commits. One notable opportunity
would be to identify aggregate objects that occur in the same place in
both initializers and do not require converison, those aggregates could
be initialized as aggregates rather than fully scalarized.
Closes#56067
---------
Co-authored-by: Finn Plummer <50529406+inbelic@users.noreply.github.com>
Co-authored-by: Helena Kotas <hekotas@microsoft.com>
Co-authored-by: Justin Bogner <mail@justinbogner.com>
The operators did not have a _Compare template arguement. The fix
updates the generic container test to use allocators for all types used.
No other issues were found.
Fixes: #127095
`__init(const value_type*, size_type, size_type)` is part of our ABI,
but we don't actually use the function anymore in the dylib. THis moves
the definition to the `src/` directory to make it clear that the code is
unused. This also allows us to remove it entirely in the unstable ABI.
Move up replaceSymbolicStrideSCEV before isNoWrap. It needs to be called
after hasComputableBounds, as this may create an AddRec via PSE, which
replaceSymbolicStrideSCEV will look up.
This is in preparation for simplifying isNoWrap.
We have some benchmarks that were benchmarking very specific
functionality, namely the optimizations in vector<bool>::iterator. Call
this out in the benchmarks by renaming them appropriately. In the future
we will also increase the coverage of these benchmarks to test other
containers.
We already handle the simpler VPERMV3(LO,MASK,HI) fold which can reuse
the (widened) mask, this attempts to match the flipped concatenation,
and commutes the mask to handle the flip.
I've limited this to cases where we can extract the constant mask for
commutation, a more general solution would XOR the MSB of the shuffle
mask indices to commute, but this almost never constant folds away after
lowering so the benefit was minimal.
Apparently trying to lookup a function pointer using the C api
`mlirExecutionEngineLookup` will throw an assert instead of just
returning a nullptr on builds with asserts.
The docs itself says it returns a nullptr when no function is found so
it should be sensible to not throw an assert in this case.
This partially reverts commit 5f2389d4. That commit started checking
whether <features.h> was a valid include unconditionally, however codebases
are free to have such a header on their search path, which breaks compilation.
LLVM libc now provides a more standard way of getting configuration macros
like __LLVM_LIBC__.
After this patch, we only include <features.h> when we're on Linux or
when we're compiling for GPUs.
