LLVM and SPIRV-LLVM-Translator pulldown (WW05) #3094
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
Exploits the instruction xxsplti32dx. It can be used to materialize any 64 bit scalar/vector splat by using two instances, one for the upper 32 bits and the other for the lower 32 bits. It should not materialize the cases which can be materialized by using the instruction xxspltidp. Differential Revision: https://https://reviews.llvm.org/D90173
Differential Revision: https://reviews.llvm.org/D95041
We already handle "vperm2x128 (ins ?, X, C1), (ins ?, X, C1), 0x31" for shuffling of the upper subvectors, but we weren't dealing with the case when we were splatting the upper subvector from a single source.
getAPIntValue returns a const APInt& so keep it as a reference.
…essiblemem_or_argmemonly Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D94850
This reverts commit 275f30d. As noted on the code review (https://reviews.llvm.org/D92892), this change causes us to reject valid code in a few cases. Reverting so we have more time to figure out what the right fix{es are, is} here.
…TRUNCATE" It caused "Vector shift amounts must be in the same as their first arg" asserts in Chromium builds. See the code review for repro instructions. > Add DemandedElts support inside the TRUNCATE analysis. > > Differential Revision: https://reviews.llvm.org/D56387 This reverts commit cad4275.
When using 2 InlinePass instances in the same CGSCC - one for other mandatory inlinings, the other for the heuristic-driven ones - the order in which the ImportedFunctionStats would be output-ed would depend on the destruction order of the inline passes, which is not deterministic. This patch moves the ImportedFunctionStats responsibility to the InlineAdvisor to address this problem. Differential Revision: https://reviews.llvm.org/D94982
F18 Clause 19.4p9 says:
The associate names of an ASSOCIATE construct have the scope of the
block.
Clause 11.3.1p1 says the ASSOCIATE statement is not itself in the block:
R1102 associate-construct is: associate-stmt block end-associate-stmt
Associate statement associations are currently fully processed from left
to right, incorrectly interposing associating entities earlier in the
list on same-named entities in the host scope.
1 program p
2 logical :: a = .false.
3 real :: b = 9.73
4 associate (b => a, a => b)
5 print*, a, b
6 end associate
7 print*, a, b
8 end
Associating names 'a' and 'b' at line 4 in this code are now both
aliased to logical host entity 'a' at line 2. This happens because the
reference to 'b' in the second association incorrectly resolves 'b' to
the entity in line 4 (already associated to 'a' at line 2), rather than
the 'b' at line 3. With bridge code to process these associations,
f18 output is:
F F
F 9.73
It should be:
9.73 F
F 9.73
To fix this, names in right-hand side selector variables/expressions
must all be resolved before any left-hand side entities are resolved.
This is done by maintaining a stack of lists of associations, rather
than a stack of associations. Each ASSOCIATE statement's list of
assocations is then visited once for right-hand side processing, and
once for left-hand side processing.
Note that other construct associations do not have this problem.
SELECT RANK and SELECT TYPE each have a single assocation, not a list.
Constraint C1113 prohibits the right-hand side of a CHANGE TEAM
association from referencing any left-hand side entity.
Differential Revision: https://reviews.llvm.org/D95010
…sor" This reverts commit e8aec76.
Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D94545
Run the ObjCARCContractPass during LTO. The legacy LTO backend (under LTO/ThinLTOCodeGenerator.cpp) already does this; this diff just adds that behavior to the new LTO backend. Without that pass, the objc.clang.arc.use intrinsic will get passed to the instruction selector, which doesn't know how to handle it. In order to test both the new and old pass managers, I've also added support for the `--[no-]lto-legacy-pass-manager` flags. P.S. Not sure if the ordering of the pass within the pipeline matters... Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D94547
... to reduce headers dependency. Reviewed By: rampitec, arsenm Differential Revision: https://reviews.llvm.org/D95036
…ange Also adds a isInput interface method.
As proposed in WebAssembly/simd#383. Differential Revision: https://reviews.llvm.org/D95012
_ExtInt gets stuck in the device-type-checking for __int128 if it is between 65 and 128 bits inclusive. Anything larger or smaller was permitted despite this, so this is simply enabling 65-128 bit _ExtInts. _ExtInt is supported on all our current ABIs, but we stil use the hasExtIntType in the target info to differentiate here so that it can be disabled.
Move the unit test from InputOutputTest.cpp to FrontendActionTest.cpp and re-implement it in terms of the FrontendActionTest fixture. This is just a small code clean-up and a continuation of: * https://reviews.llvm.org/D93544 Moving forward, we should try be implementing all unit-test cases for Flang's frontend actions in terms of FrontendActionTest. Reviewed By: sameeranjoshi Differential Revision: https://reviews.llvm.org/D94922
Branch/assume conditions in PredicateInfo are currently handled in a rather ad-hoc manner, with some arbitrary limitations. For example, an `and` of two `icmp`s will be handled, but an `and` of an `icmp` and some other condition will not. That also includes the case where more than two conditions and and'ed together. This patch makes the handling more general by looking through and/ors up to a limit and considering all kinds of conditions (though operands will only be taken for cmps of course). Differential Revision: https://reviews.llvm.org/D94447
[libomptarget][devicertl][nfc] Remove some cuda intrinsics, simplify Replace __popc, __ffs with clang intrinsics. Move kmpc_impl_min to only file that uses it and replace template with explictly typed. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D95060
The relocation offsets were incorrect. I fixed them with llvm-readobj -codeview -codeview-subsection-bytes, which has a helpful printout of the relocations that apply to a given symbol record with their offsets. With this, I was able to update the relocation offsets in the yaml to fix the line table and the S_DEFRANGE_REGISTER records. There is still some remaining inconsistency in yaml2obj and obj2yaml when round tripping MSVC objects, but that isn't a blocker for relanding D94267.
This reverts commit 079e664. It needs more work.
[libomptarget][devicertl][nfc] Simplify target_atomic abstraction Atomic functions were implemented as a shim around cuda's atomics, with amdgcn implementing those symbols as a shim around gcc style intrinsics. This patch folds target_atomic.h into target_impl.h and folds amdgcn. Further work is likely to be useful here, either changing to openmp's atomic interface or instantiating the templates on the few used types in order to move them into a cuda/c++ implementation file. This change is mostly to group the remaining uses of the cuda api under nvptx' target_impl abstraction. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D95062
…lize it" This reverts commit 5b7aef6 and relands 6529d7c. The ASan error was debugged and determined to be the fault of an invalid object file input in our test suite, which was fixed by my last change. LLD's project policy is that it assumes input objects are valid, so I have added a comment about this assumption to the relocation bounds check.
Duplicate some existing and/or tests using logical form.
Following `7169d3a315f4cdc19c4ab6b8f20c6f91b46ba9b8`, this patch updates the short option for the plugin command option to (`-p` to `-P`) to align with the `process attach` command options. The long option remains the same since there are already the same for both commands. Signed-off-by: Med Ismail Bennani <[email protected]>
Teach PredicateInfo to handle logical and/or the same way as bitwise and/or. This allows handling logical and/or inside IPSCCP and NewGVN.
Like SubView, SubTensor/SubTensorInsertOp are allowed to have rank-reducing/expanding semantics. In the case of SubTensorInsertOp , the rank of offsets/sizes/strides should be the rank of the destination tensor. Also, add a builder flavor for SubTensorOp to return a rank-reduced tensor. Differential Revision: https://reviews.llvm.org/D95076
[libomptarget][devicertl] Drop templated atomic functions The five __kmpc_atomic templates are instantiated a total of seven times. This change replaces the template with explictly typed functions, which have the same prototype for amdgcn and nvptx, and implements them with the same code presently in use. Rolls in the accepted but not yet landed D95085. The unsigned long long type can be replaced with uint64_t when replacing the cuda function. Until then, clang warns on casting a pointer to one to a pointer to the other. Reviewed By: tianshilei1992 Differential Revision: https://reviews.llvm.org/D95093
Because we were not looking for the llvm.coro.id.async intrinsic in the early coro pass which triggers follow-up passes we relied on the llvm.coro.end intrinsic being present. This might not be the case in functions that end in unreachable code. Differential Revision: https://reviews.llvm.org/D95144
The existing code did not deal with atomic loads correctly. Such loads are represented as MemoryDefs. Bail out on any MemoryAccess that is not a MemoryUse.
The title says it all. Differential Revision: https://reviews.llvm.org/D95233
…vector matching Simplify vperm2x128(concat(X,Y),concat(Z,W)) folding. Use collectConcatOps / ISD::INSERT_SUBVECTOR to find the source subvectors instead of hardcoded immediate matching.
…m2x128(permute/shift(x,c),undef) cases Fold vperm2x128(permute/shift(x,c),undef) -> permute/shift(vperm2x128(x,undef),c)
…(movddup(x),movddup(y)) cases Fold vperm2x128(movddup(x),movddup(y)) -> movddup(vperm2x128(x,y))
On z/OS, the following error message is not matched correctly in lit tests. This patch updates the CHECK expression to match the end period successfully. ``` EDC5129I No such file or directory. ``` Differential Revision: https://reviews.llvm.org/D94239
This patch implements codegen for __managed__ variable attribute for HIP. Diagnostics will be added later. Differential Revision: https://reviews.llvm.org/D94814
CONFLICT (content): Merge conflict in clang/include/clang/Basic/Attr.td
BuiltIn Decorations have their own Enabling Capabilities, so report those capabilities when emitting a BuiltIn Decoration.
Various SPIR-V subgroup operations return a boolean value, whereas the equivalent OpenCL builtins return a zero or non-zero integer value. Until now, the SPIR-V to OpenCL conversion would yield a truncate to convert from integer to boolean, which is incorrect because any non-zero integer value should be treated as a "true" value. Use a compare for the conversion instead. Also rename the helper function to reflect better what it does and add some comments.
39a2a23 commit changes parsing logic for Lang and CodeGen options. That affects SYCL specific options. The definition of impacted options is updated to match new logic.
|
/Summary:run |
S -> s |
|
/summary:run |
vladimirlaz
requested review from
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
elizabethandrews,
mdtoguchi and
premanandrao
as code owners
iclsrc
pushed a commit
that referenced
this pull request
Mar 28, 2025
Co-authored-by: Ashbaugh, Ben <[email protected]> Co-authored-by: Sven van Haastregt <[email protected]> Signed-off-by: Sidorov, Dmitry <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@739b46c4d90015a
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@622eaa4
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@bec81d1