Summary:
We used to inherit these flags from the LLVM options in a runtimes
build. This patch adds them back in manually as they are helpful for
diagnostics and optimizing the created binary.
Currently, there are a couple dead links in the comment surrounding the
tablegen implementtion of the GHC calling convention in AArch64. There
was some refactoring in GHC that moved things around. This patch fixes
up the comment to match the current state of the repository to make it
easier for future readers to reference the relevant documentation.
Summary:
There are a few default options that LLVM adds that can be problematic
for runtimes builds. These options are generally intended to handle
building LLVM itself, but are also added when building in a runtimes
mode. One such issue I've run into is that in `libc` we deliberately use
`--target` to use a different device toolchain, which doesn't support
some linker arguments passed via `-Wl`. This is observed in
https://github.com/llvm/llvm-project/pull/73030 when attempting to use
these options.
This patch completely removes these default arguments.
The consensus is that any issues created by this patch should ultimately
be solved on a per-runtime basis.
There is no point in keeping GenericDeviceTy objects alive longer than
the associated GenericPluginTy. Instead of the old API we now tear them
down with the plugin, avoiding ordering issues.
I came across an undefined behavior when running Support unit tests with
UBSAN on Windows.
```bash
[ RUN ] LEB128Test.SLEB128Size
C:\llvm\unittests\Support\LEB128Test.cpp:382:3: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long'; cast to an unsigned type to negate this value to itself
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior C:\llvm\unittests\Support\LEB128Test.cpp:382:3 in
```
UBSAN did not report the same error on macOS, but the negation still
seemed invalid (`0x8000000000000000LL == -0x8000000000000000LL`
evaluated to `true`).
I can confirm that `-0x7fffffffffffffffLL - 1` results in the expected
value on both platforms.
512bit vpbroadcastw is available only with AVX512BW. Avoid lowering
BUILD_VEC into vbroard_cast node when the condition is not met. This
fixed a crash (see the added new test).
The order in which we deinit things, especially when shared libraries
are involved, is complicated. To simplify our lives the nextgen plugin
deinitializes the GenericPluginTy and subclasses automatically. The old
__tgt_rtl_deinit_plugin is not needed anymore.
NFC processing time script identifies tests by output filename.
When `/dev/null` is used as output filename, we're unable to tell the
source test, and the reports are unhelpful.
Replace `/dev/null/` with `%t.null` which resolves the issue.
Try to pick the FP register bank based on surrounding use/defs. Code is
basically copied from AArch64.
Need legalizer changes to make this more useful. Right now we're stuck
with only being able to FP select types less than or equal to XLen.
Most of the tests were failing with the following in their logs..
| /usr/bin/ld: /home/brad/llvm-build/runtimes/runtimes-bins/openmp/runtime/src/libomp.so:
warning: Warning: reference to the libc supplied alloca(3); this most likely will not
work. Please use the compiler provided version of alloca(3), by supplying the appropriate
compiler flags (e.g. -std=gnu99).
By making use of __builtin_alloca..
before:
Total Discovered Tests: 353
Unsupported: 59 (16.71%)
Passed : 51 (14.45%)
Failed : 243 (68.84%)
after:
Total Discovered Tests: 353
Unsupported: 59 (16.71%)
Passed : 290 (82.15%)
Failed : 4 (1.13%)
SymbolStringPoolEntryUnsafe provides unsafe access to SymbolStringPtr objects,
allowing clients to manually retain and release pool entries, or consume or
create SymbolStringPtr instances without affecting an entry's ref-count. This
can be useful when writing C APIs that need to handle SymbolStringPtrs.
As part of this patch the LLVM-C API implementation is updated to use the new
utility, rather than the old, private OrcV2CAPIHelper utility.
Previously the pattern only worked when the permutation map was a minor
identity. Infer the new mask type from the new transfer map after
dropping leading unit dims.
This patch fixes one case where the decoding member function `in()` was
returning `partial` instead of `error`. Additionally, it adds large
testsuite that tests all `codecvt` facets that were added in C++11 and
in C++20. The testsuite covers this bug.
Fixes#60177.
1. Differentiate SANITIZER_WINDOWS64 for x64 and arm64
2. turn off interception tests that expect x86 assembly
---------
Co-authored-by: Farzon Lotfi <farzon@farzon.com>
llvm-readobj and llvm-objdump have inconsistent handling of display
lma for sections.
This patch tries to common code up and adapt the same approach for
both tools.
This reverts commit 79b03306af.
I am seeing very confusing errors with the `libomptarget` test suite
when using dlopen / other flags. Reverting to investigate why this is.
Cleanup work towards removing the method Type::getPointerTo.
If a call to Type::getPointerTo is used solely to support an unneeded
pointer-cast, remove the call entirely.
This change is motived by a point of confusion on
https://github.com/llvm/llvm-project/pull/71764. I hadn't fully
understood why doPeepholeMaskedRVV needed to be part of the same change.
As indicated in the fixme in this patch, the reason is that
performCombineVMergeAndVOps doesn't know how to deal with the true side
of the merge being a all-ones masked instruction.
This change removes one of two calls to the routine in
RISCVISELDAGToDAG, and adds a clarifying comment on the precondition for
the remaining call. The post-ISEL code is tested by the cases where we
can form a unmasked instruction after folding the vmerge back into true.
I don't really care if we actually land this patch, or leave it roled
into https://github.com/llvm/llvm-project/pull/71764. I'm posting it
mostly to clarify the confusion.
The motivation for this change is explained in
https://github.com/llvm/llvm-project/issues/72354.
Before this change, we could not tell between signed/unsigned
minimum/maximum and NaN treatment for floating point values.
The mapping of old reduction operations to the new ones is as follows:
* `min` --> `minsi` for ints, `minf` for floats
* `max` --> `maxsi` for ints, `maxf` for floats
New reduction kinds not represented in the old enum: `minui`, `maxui`,
`minimumf`, `maximumf`.
As a next step, I would like to have a common definition of combining
kinds used by the `vector` and `gpu` dialects. Separately, the GPU to
SPIR-V lowering does not yet properly handle zero and NaN values -- the
behavior of floating point min/max group reductions is not specified by
the SPIR-V spec, see https://github.com/llvm/llvm-project/issues/73459.
Issue: https://github.com/llvm/llvm-project/issues/72354
Instead of extracting all individual vector components and performing a
scalar summation, use `spirv.Dot` with the original reduction operand
and a vector constant of all ones.
We simplify the floating point properties by splitting concerns:
- We define all distinct floating point formats in the `FPType` enum.
- We map them to properties via the `FPProperties` trait.
- We map from C++ type to `FPType` in the `getFPType` function so logic
is easier to understand and extend.
Several experimental headers around std::pmr have been slated for
removal for a while now. This patch actually performs the removal and
cleanups from the code base.
For most practical purposes, the only KnownBits patterns we care about are
those involving a constant comparison RHS and constant mask. However,
the actual implementation is written in a very general way -- and of
course, with basically no test coverage of those generalizations.
This patch reduces the implementation to only handle cases with constant
operands. The test changes are all in "make sure we don't crash" tests.
The motivation for this change is an upcoming patch to handling dominating
conditions in computeKnownBits(). Handling non-constant RHS would add
significant additional compile-time overhead in that case, without any
significant impact on optimization quality.
https://reviews.llvm.org/D151863 (2023-05) removed
`BaseReg = BaseReg ? BaseReg : 1` (introduced in commit
175d0aeef3 (2013)) and caused a
regression: ensuring a non-zero `BaseReg` was to treat
`static void (*fptr)(); __asm { call fptr }` as non-`AbsMem`
`AsmOperandClass` and generate `call $0`/`callq *fptr(%rip)` instead of
`call ${0:P}`/`callq *fptr`
(The asm template argument modifier `P` is for call targets, while
no modifier is used by other instructions like `mov rax, fptr`)
This patch reinstates the BaseReg-setting statement but places it inside
`if (IsGlobalLV)` for clarify.
The special case is unfortunate, but we also have special case in
similar places (https://reviews.llvm.org/D149920).
Fix: #73033
Found while running libc++'s test suite with MSVC's STL, where we use
both Clang and MSVC's compiler.
libc++'s test suite has started using some C++23 Core Language features
that MSVC hasn't implemented yet. When avoiding these features costs
just a tiny bit of syntax, I would like to ask libc++ to consider making
that change in the interest of practical portability, at least until
MSVC catches up. If there's no desire to do so, then I could skip the
affected tests, but that would make me a slightly sad kitty.
Certain `awaitable` types could be safe to `co_await` on even when we
have suspension-hostile RAII objects in scope.
This PR adds a way for users to mark such safe `awaitable` and silence
false positive warnings in `co_await` expressions involving such an
`awaitable`.
`co_await`-ing an expression of `awaitable` type is considered safe if
the type is part of `SafeAwaiatablesList` check option. RAII objects
persisting across such a `co_await` expression are
considered safe and hence are not flagged.
