| Age | Commit message (Collapse) | Author |
|---|
|
This was missed in 0ef522ff68fff4266bf85e7b7a507a16a8fd34ee
|
|
I think we need to keep the SelectionDAG code for volatile load/store so
we should support 4 byte alignment when possible.
|
|
(#168661)"
This reverts commit 0859ac5866a0228f5607dd329f83f4a9622dedcc.
This caused a couple test failures, likely due to a mid-air collision.
Reverting for now to get the tree back to green and allow the original
author to run UTC/friends and verify the output.
|
|
Fixes #118187
Fixes #156579
An instantiated `LambdaExpr` can currently be marked as
`LDK_NeverDependent` if it's nested within a generic lambda. If that
`LambdaExpr` in fact depends on template parameters introduced by the
enclosing generic lambda, then its dependence will be misreported as
"never dependent" and spurious diagnostics can result.
The fix here proposed is a bit ugly, but the condition that it's being
bolted onto already seems like a bit of a hack, so this seems no worse
for wear.
Note that #89702 surfaced this change because it caused the inner lambda
expression to (correctly) be considered in a constant-evaluated context.
The affected check for whether to mark the inner lambda as
`LDK_NeverDependent` therefore started to apply, whereas it didn't
before.
**Tested**: `check-clang` and `check-cxx`.
|
|
This maybe a bug which is introduced by commit
6749ae36b4a33769e7a77cf812d7cd0a908ae3b9, and has been present ever
since.
In this case, `OtherReg` always overlaps with `DstReg` cause they from
the `Copy` all.
|
|
This improves type safety and is less verbose. Use SimpleTy only where
an integer is needed like switches or emitting a VBR.
---------
Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
|
|
|
|
|
|
Identified with modernize-loop-convert.
|
|
Identified with modernize-loop-convert.
|
|
While I am at it, this patch uses const l-value references for
std::shared_ptr. We don't need to increment the reference count by
passing std::shared_ptr by value.
Identified with llvm-use-ranges.
|
|
Identified with llvm-use-ranges.
|
|
Identified with bugprone-unused-local-non-trivial-variable.
|
|
Example based on the gfortran test a.6.1.f90
```
do 100 i = 1,10
!$omp do
do 100 j = 1,10
call work(i,j)
100 continue
```
During canonicalization of label-DO loops, if the body of an OpenMP
construct ends with a label, treat the label as ending the construct
itself.
This will also allow handling of cases like
```
do 100 i = 1, 10
!$omp atomic write
100 x = i
```
which we were unable to before.
|
|
isUniformAcrossVFsAndUFs
Extract the PreservesUniformity logic from isSingleScalar into a shared
static helper function. Update isUniformAcrossVFsAndUFs to use this
logic for VPWidenRecipe and VPInstruction, so that any opcode that
preserves uniformity is considered uniform-across-vf-and-uf if its
operands are.
This unifies the uniformity checking logic and makes it easier to extend
in the future.
This should effectively by NFC currently.
|
|
- Support serialization of the number of allocated preload kernarg SGPRs
- Support serialization of the first preload kernarg SGPR allocated
Together they enable reconstructing correctly MIR with preload kernarg
SGPRs.
|
|
(#169188)
…ls, NFC
|
|
The GNU documentation is ambiguous about the version index for
unversioned undefined symbols. The current specification at
https://sourceware.org/gnu-gabi/program-loading-and-dynamic-linking.txt
defines VER_NDX_LOCAL (0) as "The symbol is private, and is not
available outside this object."
However, this naming is misleading for undefined symbols. As suggested
in
discussions, VER_NDX_LOCAL should conceptually be VER_NDX_NONE and apply
to unversioned undefined symbols as well.
GNU ld has used index 0 for unversioned undefined symbols both before
version 2.35 (see https://sourceware.org/PR26002) and in the upcoming
2.46 release (see https://sourceware.org/PR33577). This change aligns
with GNU ld's behavior by switching from index 1 to index 0.
While here, add a test to dso-undef-extract-lazy.s that undefined
symbols of index 0 in DSO are treated as unversioned symbols.
|
|
Create phi recipes for scalar resume value up front in addInitialSkeleton during initial construction. This will allow moving the remaining code dealing with resume values to VPlan transforms/construction.
PR: https://github.com/llvm/llvm-project/pull/166099
|
|
|
|
If a threading path has cycles within it then the transformation is not
correct. This patch fixes a couple of cases that create such cycles.
Fixes https://github.com/llvm/llvm-project/issues/166868
|
|
Previously, loop constructs were parsed in a piece-wise manner: the
begin directive, the body, and the end directive were parsed separately.
Later on in canonicalization they were all coalesced into a loop
construct. To facilitate that end-loop directives were given a special
treatment, namely they were parsed as OpenMP constructs. As a result
syntax errors caused by misplaced end-loop directives were handled
differently from those cause by misplaced non-loop end directives.
The new loop nest parser constructs the complete loop construct,
removing the need for the canonicalization step. Additionally, it is the
basis for parsing loop-sequence-associated constructs in the future.
It also removes the need for the special treatment of end-loop
directives. While this patch temporarily degrades the error messaging
for misplaced end-loop directives, it enables uniform handling of any
misplaced end-directives in the future.
|
|
PyYAML is not an actual use-time/runtime dependency of our bindings. It
is necessary only if someone wants to regenerate
`LinalgNamedStructuredOps.yaml`:
https://github.com/llvm/llvm-project/blob/93097b2d47c87bf5eee0a2612d961c7a01831eab/mlir/tools/mlir-linalg-ods-gen/update_core_linalg_named_ops.sh.in#L29
This PR does the minimal refactor to remove the need during actual run/use time.
|
|
These aren't AVX512VL tests
|
|
VPSHUFBITQMB intrinsics to be used in constexpr (#168100)
Resolves #161337
|
|
This test was failing with the internal shell due to the use of
subshells. This was not caught in my initial round of testing due to me
only using a M4 Mac for running my tests.
|
|
only Instruction as param and drop module and target (#168276)
|
|
(#169163)
Extends the `icmp(trunc(shl))` fold to handle any power of 2 constant as
the shift base, not just 1. This generalizes the following patterns by
adjusting the comparison offsets by `log2(Pow2)`.
```llvm
(trunc (1 << Y) to iN) == 0 --> Y u>= N
(trunc (1 << Y) to iN) != 0 --> Y u< N
(trunc (1 << Y) to iN) == 2**C --> Y == C
(trunc (1 << Y) to iN) != 2**C --> Y != C
; to
(trunc (Pow2 << Y) to iN) == 0 --> Y u>= N - log2(Pow2)
(trunc (Pow2 << Y) to iN) != 0 --> Y u< N - log2(Pow2)
(trunc (Pow2 << Y) to iN) == 2**C --> Y == C - log2(Pow2)
(trunc (Pow2 << Y) to iN) != 2**C --> Y != C - log2(Pow2)
```
Proof: https://alive2.llvm.org/ce/z/2zwTkp
|
|
destroyLocals() does the same thing.
|
|
VPERMILPD/S variable mask intrinsics to be used in constexpr (#168861)
Allowing VPERMILPD/S intrinsics to be used in constexpr
Closes #167878
|
|
`[[nodiscard]]` should be applied to functions where discarding the
return value is most likely a correctness issue.
-
https://libcxx.llvm.org/CodingGuidelines.html#apply-nodiscard-where-relevant
|
|
(#167118)
It turns out that having `-ffast-math` as the only option to control
optimizations for MOD for REAL kinds (PR #160660) is too coarse-grained
for some applications. Thus, this PR adds back `-ffast-real-mod` to have
more control over the optimization. The `-ffast-math` flag will still
enable the optimization, and `-fno-fast-real-mod` allows one to disable
it.
|
|
evaluation (#168206)
Fixes #167681
|
|
This patch upstreams CIR support for atomic operations with memory
orders that are not known at compile time.
|
|
These are not incompatible; allow them to be combined.
|
|
For swift async code, we need to use a debug intrinsic that behaves like
an llvm.dbg.declare but can take any location type rather than just a
pointer or integer.
To solve this, a new debug instrinsic called llvm.dbg.declare_value has
been created, which behaves exactly like an llvm.dbg.declare but can
take non pointer and integer location types.
More information here:
https://discourse.llvm.org/t/rfc-introduce-new-llvm-dbg-coroframe-entry-intrinsic/88269
This is the first patch as part of a stack of patches, with the one
succeeding it being: https://github.com/llvm/llvm-project/pull/168134
|
|
Function &F is the more standard abbreviation (~4000 uses in llvm versus
~300 uses).
|
|
```
>>> "_target-has-llvm-21 || target={{.+}}-apple-macosx{{26.[0-9](.\d+)?}}" == r"_target-has-llvm-21 || target={{.+}}-apple-macosx{{26.[0-9](.\\
d+)?}}"
<python-input-6>:1: SyntaxWarning: invalid escape sequence '\d'
True
>>> "_target-has-llvm-20 || target={{.+}}-apple-macosx{{15.[4-9](.\d+)?}}" == r"_target-has-llvm-20 || target={{.+}}-apple-macosx{{15.[4-9](.\\
d+)?}}"
<python-input-7>:1: SyntaxWarning: invalid escape sequence '\d'
True
>>> "_target-has-llvm-19 || target={{.+}}-apple-macosx{{15.[0-3](.\d+)?}}" == r"_target-has-llvm-19 || target={{.+}}-apple-macosx{{15.[0-3](.\\
d+)?}}"
<python-input-8>:1: SyntaxWarning: invalid escape sequence '\d'
True
>>> "_target-has-llvm-18 || target={{.+}}-apple-macosx{{14.[4-9](.\d+)?}}" == r"_target-has-llvm-18 || target={{.+}}-apple-macosx{{14.[4-9](.\\
d+)?}}"
<python-input-9>:1: SyntaxWarning: invalid escape sequence '\d'
True
```
|
|
...in preparation for https://github.com/llvm/llvm-project/pull/168826
as requested in the review.
Co-authored-by: Hristo Hristov <zingam@outlook.com>
|
|
We can't access the calling frame in that case.
Fixes https://github.com/llvm/llvm-project/issues/169032
|
|
Removed duplicated checks reported by cppcheck
|
|
In C++17, static constexpr members are implicitly inline, so they no
longer require an out-of-line definition.
Identified with readability-redundant-declaration.
|
|
Reverts llvm/llvm-project#167879
This PR is causing assertions in the check-offload tests:
https://lab.llvm.org/staging/#/builders/105
https://lab.llvm.org/staging/#/builders/105/builds/37057
|
|
supports -fbounds-safety (#169112)
This patch makes it possible to detect in LLDB shell and API tests if
`-fbounds-safety` is supported by the compiler used for testing. The
motivation behind this is to allow upstreaming
https://github.com/swiftlang/llvm-project/pull/11835 but with the tests
disabled in upstream because the full implementation of -fbounds-safety
isn't available in Clang yet.
For shell tests when -fbounds-safety is available the
`clang-bounds-safety` feature is available which means tests can be
annotated with `# REQUIRES: clang-bounds-safety`.
API tests that need -fbounds-safety support in the compiler can use the
new `@skipUnlessBoundsSafety` decorator.
rdar://165225507
|
|
(#169116)
This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two
dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and
c243406a695ca056a07ef4064b0f9feee7685320, see discussion in
https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.
|
|
(#167825)
Currently, if multiple external weak symbols are defined at the same
address in an object file (e.g., by using the .set assembler directive
to alias them to a single weak variable), ld64.lld treats them as a
single unit. When any one of these symbols is overridden by a strong
definition, all of the original weak symbols resolve to the strong
definition.
This patch changes the behavior in `transplantSymbolsAtOffset`. When a
weak symbol is being replaced by a strong one, only non-external (local)
symbols at the same offset are moved to the new symbol's section. Other
*external* symbols are no longer transplanted.
This allows each external weak symbol to be overridden independently.
This behavior is consistent with Apple's ld-classic, but diverges from
ld-prime in one case, as noted on
https://github.com/llvm/llvm-project/issues/167262 (this discrepancy has
recently been reported to Apple).
### Backward Compatibility
This change alters linker behavior for a specific scenario. The creation
of multiple external weak symbols aliased to the same address via
assembler directives is primarily an advanced technique. It's unlikely
that existing builds rely on the current behavior of all aliases being
overridden together.
If there are concerns, this could be put behind a linker option, but the
new default seems more correct, less surprising, and is consistent with
ld-classic.
### Testing
The new lit test `test/MachO/weak-alias-override.s` verifies this
behavior using llvm-nm.
Fixes #167262
|
|
Before, we were unconditionally writing a message. After this patch, we
only write a message when the tests failed, or there is already an
existing comment. This is how this workflow was intended to work
originally, but is not how it ended up working, mostly due to my
misconceptions around how the existing code formatter pass handled this
case (we need to actually not write out any comments, not write out a
specific message).
|
|
The default of this has been flipped since we're on 8.x
|
|
This implements the builtins that handle overflow.
This fixes issue https://github.com/llvm/llvm-project/issues/163888
|
|
It seems like this fails on macOS with C++20
|
