LLVM and SPIRV-LLVM-Translator pulldown (WW13 2024) #13190
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We can canonicalize the complex.div if the divisor is one (real = 1.0, imag = 0.0) with the input number itself. Ref: https://www.cuemath.com/numbers/division-of-complex-numbers/
Copy OtherPredicates from Pseudo to Real. Real should inherit predicates from the corresponding Pseudo
…85497) This is in preparation for implementing go-to-definition support on type inlay hints, switching the `label` field within the InlayHint protocol from a string to an array of `InlayHintLabelPart`.
To reduce the indentation by using early returns, this patch hoist the return for illegal type and non vector type earlier. It should mostly be an NFC.
And add a driver test missing from the original patch #65996.
When printing an `_Atomic(some struct type)`, we would later run into an assertion because we do a `Ty->castAs<RecordType>()`, which doesn't work with an `AtomicType`.
…(#86514) The IR for a double-to-i129 conversion looks like this in one of the blocks in compiler-rt: %cmp5.i = icmp ult i16 %3, -129, !dbg !24 But in ExpandLargeFpConvert, it looks like: %13 = icmp ult i129 %12, 4294967167, !dbg !19 ExpandLargeFpConvert is wrong; the value should have been signed before negating, but instead we get a very large unsigned value. Another value in the same pass also has this issue.
Replicated from SDAG.
Ideally, header files should be used by only one target, but this is hard because CMake is less strict with headers (no layering check). But even with bazel, headers should only be exported once in the `hdrs` attribute. Other targets may use them in the `srcs` attribute to avoid circular dependencies.
This non-functional change eliminates the compiler warning
```
/repo/llvm-project/clang/include/clang/Basic/SyncScope.h: In member function ‘virtual bool clang::AtomicScopeGenericModel::isValid(unsigned int) const’:
/repo/llvm-project/clang/include/clang/Basic/SyncScope.h:255:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
return S >= static_cast<unsigned>(System) &&
~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
which was appearing repeatedly, as this header is included into very
many source files (through various chains of 6-7 header files).
Similar to #85625, some of the codegen is still far from optimal but this helps fix quite a few fallback cases.
…ents on targets using scratch instructions for stack #78226" (#86273) Reverts llvm/llvm-project#81394 This reverts commit 3ac243b. It is not handling RSrc registers s0-s3 correctly. This leads to a broken test, where it expects s0-s3 as function argument and uses it as RSrc register as well. We need to re-visit the patch, but apparently we only want to have s0-s3 as argument registers if we don't need them as RSrc registers.
…86260) Add operation mapping to the LLVM `llvm.experimental.constrained.fptrunc.*` intrinsic. The new operation implements the new `LLVM::FPExceptionBehaviorOpInterface` and `LLVM::RoundingModeOpInterface` interfaces. --------- Signed-off-by: Victor Perez <victor.perez@codeplay.com>
… (#86487) Handle the case where we've ended up inserting back into the source vector we extracted the subvector from.
…ift amount Noticed while trying to compare splat vs per-element shift perf stats for #39424 Confirmed with uops.info
…ing prior to legalization Fixes issue where AVX1 targets weren't matching 256-bit AVGCEILU cases.
Fixes #83561. When a thread is blocked on a mutex and we send an async signal to that mutex, it never arrives because tsan thinks that `pthread_mutex_lock` is not a blocking function. This patch marks `pthread_*_lock` functions as blocking so we can successfully deliver async signals like `SIGPROF` when the thread is blocked on them. See the issue also for more details. I also added a test, which is a simplified version of the compiler explorer example I posted in the issue. Please let me know if you have any other ideas or things to improve! Happy to work on them. Also I filed #83844 which is more tricky because we don't have a libc wrapper for `SYS_futex`. I'm not sure how to intercept this yet. Please let me know if you have ideas on that as well. Thanks!
…tsan (#86537) Fixes #83844. This PR adds callbacks to mark futex syscalls as blocking. Unfortunately we didn't have a mechanism before to mark syscalls as a blocking call, so I had to implement it, but it mostly reuses the `BlockingCall` implementation [here](https://github.com/llvm/llvm-project/blob/96819daa3d095cf9f662e0229dc82eaaa25480e8/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp#L362-L380). The issue includes some information but this issue was discovered because Rust uses futexes directly. So most likely we need to update Rust as well to use these callbacks. Also see the latest comments in #85188 for some context. I also sent another PR #84162 to mark `pthread_*_lock` calls as blocking.
The latest ACLE allows it and further clarifies the following
in regards to the combination of the two attributes:
"If the `default` matches with another explicitly provided
version in the same translation unit, then the compiler can
emit only one function instead of the two. The explicitly
provided version shall be preferred."
("default" refers to the default clone here)
ARM-software/acle#310
…aming functions. (#85388) Similar to how we protected FP/fixed-vector arguments and results from calls, we should do the same for arguments/results from locally-streaming functions such that those are not spilled/filled as ZPR registers. This may cause a small regression (additional spills/fills), which is addressed by #85386.
Testing with MSVC link.exe showed that it respects such options, while LLD currently discards them.
CONFLICT (content): Merge conflict in clang/lib/CodeGen/CGClass.cpp CONFLICT (content): Merge conflict in clang/lib/CodeGen/CGExpr.cpp
…es (#86595) Summary: We have a plugin singleton that implements the Plugin interface. This then spawns separate device and kernels. Previously when these needed to reach into the global singleton they would use the `PluginTy::get` routine to get access to it. In the future we will move away from this as the lifetime of the plugin will be handled by `libomptarget` directly. This patch removes uses of this inside of the plugin implementaion themselves by simply keeping a reference to the plugin inside of the device. The external `__tgt_rtl` functions still use the global method, but will be removed later.
…m-link (#86274)" This reverts commit 8263a88.
jsji
force-pushed
the
llvmspirv_pulldown
branch
from
f13832f
to
023653f
Compare
|
This is ready for review.
|
|
@intel/dpcpp-tools-reviewers Can you please help review and add comments/approvals explicitly to this PR so that this can be merged. Thanks. |
Hi @jsji Thanks |
asudarsa
approved these changes
Apr 1, 2024
For sycl branch, we should be in sync with main through previous pulldown (unless I missed something.) Yes, revert is temporarily, we should track down and either fix, recover or cherry-pick required commits. Thanks @asudarsa |
|
@bader @intel/llvm-gatekeepers This is ready for merge. Thanks. |
asudarsa
reviewed
Apr 1, 2024
asudarsa
reviewed
Apr 1, 2024
| @@ -368,7 +368,7 @@ attributes #4 = { nounwind } | |||
| !11 = !{i64 0, i64 4, !9, i64 4, i64 4, !12} | |||
| !12 = !{!13, !13, i64 0} | |||
| !13 = !{!"float", !7, i64 0} | |||
| !14 = !{i64 0, i64 4, !9, i64 0, i64 4, !15} | |||
| !14 = !{i64 0, i64 4, !15} | |||
There was a problem hiding this comment.
Do we know why this started failing? I will also check
There was a problem hiding this comment.
This is exposed by the newly enabled TBAA verfier.
- df75183 - (2024-03-27) [TBAA] Add verifier for tbaa.struct metadata (#86709)
I don't think so, the whole workaround in The problem was fixed in linux driver already, but unfortunately, still not fixed yet in Windows driver. |
|
/merge |
bb-sycl
approved these changes
Apr 1, 2024
|
Mon 01 Apr 2024 04:50:39 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes. |
|
Mon 01 Apr 2024 04:55:04 PM UTC --- Merge the branch in this PR to base automatically. Will close the PR later. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LLVM: llvm/llvm-project@acdba09
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@1a1b648