LLVM and SPIRV-LLVM-Translator pulldown (WW48) #12046
Merged
Conversation
This file contains hidden or 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
This was suggested in another related review, so backporting it to the existing code as well.
...to model the results of alloca() and _alloca() calls. Previously it acted as if these functions were returning memory from the heap, which led to alpha.security.ArrayBoundV2 producing incorrect messages.
…known (#73606) If we have a high LMUL build_vector and a known exact VLEN, we can decompose the build_vector into one build_vector per register in the register group. Doing so requires exact knowledge of which elements correspond to each register in the register group, and thus an exact VLEN must be known. Since we no longer have operations which are linear (or worse) in LMUL, this also allows us to lower all build_vectors without resorting to going through the stack.
…mber declarations (#73626) In llvm/llvm-project#71780 we started emitting definitions for all static data-members with constant initialisers, even if they were constants (i.e., didn't have a location). We also dropped the DW_AT_const_value from the declaration to [help resolve inconsistencies during type merging in the DWARFParallelLinker](llvm/llvm-project#68721). However, for static data members that do have locations, we wouldn't emit a DW_AT_const_value on it, assuming that the consumer knows how to read the value using the location. This broke some consumers that really wanted to find a DW_AT_const_value. Ultimately we want to attach a DW_AT_const_value to definitions that have a location too. But to fix consumers broken by said change, this patch adds the constant back onto the declaration. This is what we used to do prior to llvm/llvm-project#71780
Also rename the fixture class since these tests are not ELF-specific.
This implements assembly support for the Debug/PMU extensions introduced as part of the Armv9.5-A architecture version. The changes include: * New ID_AA64DFR2_EL1 ID system register * New MDSTEPOP_EL1 and SPMZR_EL0 system registers Mode details about these extensions can be found at: * https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2023 * https://developer.arm.com/documentation/ddi0602/2023-09/ Co-authored-by: Oliver Stannard <[email protected]>
…ned construct (#73581) `A program may not branch into or out of a compute construct.` This restriction is also true for combined constructs. This patch enforce this rule.
Clarify how the addend is used in _HI relocation types like R_AMDGPU_ABS32_HI based on the current behaviour of the Mesa and AMDPAL ELF loaders. This affects Mesa and AMDPAL because they use REL relocation records, so the addend for these types is the 32-bit literal value from the instruction being relocated. AMDHSA is not affected because it uses RELA relocation records which have a 64-bit addend.
We can use inline constants with packed 16-bit operands, but these should use op_sel. Currently splat of inlinable constants is considered legal, which is not really true if we fail to fold it with op_sel and drop the high half. It may be legal as a literal but not as inline constant, but then usual literal checks must be performed. This patch makes these splat literals illegal but adds additional logic to the operand folding to keep current folds. This logic is somewhat heavy though. This has fixed constant bus violation in the fdot2 test.
The overhead of a library and 4 files seems high without benefit. This simply tries to consolidate our structure.
CONFLICT (content): Merge conflict in llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
This change makes x64 enablement case explicit and adds an else case for 32bit which fixes a regression on Windows i386 asan builds introduced by llvm/llvm-project#66973.
This was causing an assert on invalid in the modified test case.
Some of the files in the docs/ directory are from 2019 and haven't been updated since. This patch updates implementation_standard.rst, source_tree_layout.rst, and has some minor fixes for strings.rst. It also marks the most severely out of date files with a warning. These files will be updated in a later patch.
Similar to #73677, there is no benefit from keeping MemoryManager seperate; it's tied into the current design. Except the move I also replaced the getenv call with our Env handling.
These tests use an old way to test code in constexpr context. This changes the code to the idomatic libc++ method. This is a preparation for #73162. Side changes - Updated formatting - Made some helper functions constexpr - Some naming improvements
Both active C++ proposals (P1144 and P2786) agree that `is_trivially_relocatable_v<int&>` and `is_trivially_relocatable_v<int()>` should be false, not true. Only complete object types can be trivially relocatable. Fixes #67498
…ion (#73605) This commit allows a final progress report upon the destruction of the `Progress` object to happen at all times as opposed to when the progress was not completed.
…66) (#73680) If we have a constant index and a known vlen, then we can identify which registers out of a register group is being accessed. Given this, we can reuse the (slightly generalized) existing handling for working on sub-register groups. This results in all constant index extracts with known vlen becoming m1 operations. One bit of weirdness to highlight and explain: the existing code uses the VL from the original vector type, not the inner vector type. This is correct because the inner register group must be smaller than the original (possibly fixed length) vector type. Overall, this seems to a reasonable codegen tradeoff as it biases us towards immediate AVLs, which avoids needing the vsetvli form which clobbers a GPR for no real purpose. The downside is that for large fixed length vectors, we end up materializing an immediate in register for little value. We should probably generalize this idea and try to optimize the large fixed length vector case, but that can be done in separate work.
Information about code object version can be configured by the user for AMD GPU target and it needs to be placed in LLVM IR generated by Flang. Information about code object version in MLIR generated by the parser can be reused by other tools. There is no need to specify extra flags if we want to invoke MLIR tools (like fir-opt) separately.
Add documentation w.r.t. changes by #72606, which allows to set the dynamic callstack size.
This commit causes test errors on buildbots. This reverts commit a8ac930.
For CSEBlocks we can safely use DenseSet, the order should not be preserved for this container.
…h the AddressSanitizerOptions struct. (#72439) This patch adds the ability to pass values for the command line options of -max-inline-poisoning-size, -instrumentation-with-calls-threshold and -asan-guard-against-version-mismatch through the AddressSanitizerOptions struct. The motivation is to use these new options when using the pass in Swift. rdar://118470958
- change Scope argument to one of two available options: ScopeWorkgroup/ScopeWorkgroup - fix arguments order in calls to OpCooperativeMatrixLoadKHR() Original commit: KhronosGroup/SPIRV-LLVM-Translator@4e1d3e0
…e extension doc (#2239) Original commit: KhronosGroup/SPIRV-LLVM-Translator@55966ee
…ter (#2232) This fixes reverse translation for SPV_INTEL_fpga_memory_accesses. Theoretically it fixes more, but seems like without the extension we don't generate UserSemantic decoration in this case at all. Will be investigated separately. Signed-off-by: Sidorov, Dmitry <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@ef0165a
There is a fundamental misalignment between when translating llvm.ptr.annotation to SPIRV's OpMemberDecorate. llvm.ptr.annotation is applied onto a pointer. OpMemberDecorate is applied on a type, which means that all variables of this type will have this Decoration. This change fixes this misalignment by translating llvm.ptr.annotation to SPIRV's OpDecorate instead, which instead places the decoration onto the pointer. Original commit: KhronosGroup/SPIRV-LLVM-Translator@3770469
sys-ce-bb
added
the
disable-lint
sys-ce-bb
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
afe8b93 2023-11-25 [clang] Avoid memcopy for small structure with padding under -ftrivial-auto-var-init (#71677) [email protected] Removed a call to memcopy, so we have 1 less attr.
The difference is due to revert in #10950
|
This is ready for review.
|
premanandrao
approved these changes
Dec 1, 2023
|
@bader @intel/llvm-gatekeepers This is ready for merge. Thanks. |
|
/merge |
bb-sycl
approved these changes
Dec 1, 2023
|
Fri 01 Dec 2023 05:01:46 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes. |
|
Fri 01 Dec 2023 05:07:31 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@225648e
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@3770469