LLVM and SPIRV-LLVM-Translator pulldown (WW46-47) #4993
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
…, cost is same as for `*ext v32i1 to v32i16` Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D113914
Differential Revision: https://reviews.llvm.org/D114038
… distributions Differential Revision: https://reviews.llvm.org/D113260
The information in these perations is used by other operation. At this point they should not have anymore uses. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113971 Co-authored-by: Eric Schweitz <[email protected]>
Delegate updating of LiveIntervals to each target's convertToThreeAddress implementation, instead of repairing LiveIntervals after the fact in TwoAddressInstruction::convertInstTo3Addr. Differential Revision: https://reviews.llvm.org/D113493
Add test coverage for a problem that was fixed by D113493: when updating live intervals, fix handling of live ranges that were previously tied to an early-clobber def but no longer are.
Currently the stepvector intrinsic only supports element types that are integers of size 8 bits or more. This patch adds support for the creation of stepvectors with smaller element types by creating the intrinsic with i8 elements that we then truncate to the requested size. It's not currently possible to write a vectoriser test to exercise this code path so I have added a unit test here: llvm/unittests/IR/IRBuilderTest.cpp Differential Revision: https://reviews.llvm.org/D113767
…th compiler implied -lunwind" This reverts commit 7c3d19a. This commit was reported as causing build problems for the amdgpu buildbot in https://reviews.llvm.org/D113253#3137097.
Similar other cases in the current function (e.g. when the step is 1 or -1), applying loop guards can lead to tighter upper bounds for the backedge-taken counts. Fixes PR52464. Reviewed By: reames, nikic Differential Revision: https://reviews.llvm.org/D113578
This patch adds the conversion pattern for `fir.box_tdes`. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113931 Co-authored-by: Eric Schweitz <[email protected]>
There are various tests that need to be adjusted to test the right thing with instruction referencing -- usually because the internal representation of variables is different, sometimes that location lists change. This patch makes a bunch of tests explicitly not use instruction referencing, so that a check-llvm test with instruction referencing on for x86_64 doesn't fail. I'll then convert the tests to have instr-ref CHECK lines, and similar. Differential Revision: https://reviews.llvm.org/D113194
When asking how many parts are required for a scalable vector type there are occasions when it cannot be computed. For example, <vscale x 1 x i3> is one such vector for AArch64+SVE because at the moment no matter how we promote the i3 type we never end up with a legal vector. This means that getTypeConversion returns TypeScalarizeScalableVector as the LegalizeKind, and then getTypeLegalizationCost returns an invalid cost. This then causes BasicTTImpl::getNumberOfParts to dereference an invalid cost, which triggers an assert. This patch changes getNumberOfParts to return 0 for such cases, since the definition of getNumberOfParts in TargetTransformInfo.h states that we can use a return value of 0 to represent an unknown answer. Currently, LoopVectorize.cpp is the only place where we need to check for 0 as a return value, because all other instances will not currently ask for the number of parts for <vscale x 1 x iX> types. In addition, I have changed the target-independent interface for getNumberOfParts to return 1 and assume there is a single register that can fit the type. The loop vectoriser has lots of tests that are target-independent and they relied upon the 0 value to mean the answer is known and that we are not scalarising the vector. I have added tests here that show we correctly return an invalid cost for VF=vscale x 1 when the loop contains unusual types such as i7: Transforms/LoopVectorize/AArch64/sve-inductions-unusual-types.ll Differential Revision: https://reviews.llvm.org/D113772
Add !fir.tdesc type conversion. !fir.tdesc is converted to a llvm.ptr<i8>. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113769 Co-authored-by: Eric Schweitz <[email protected]> Co-authored-by: Jean Perier <[email protected]>
… -> and(x,c') If we've only demanded the 0'th element, and it comes from a (one-use) AND, try to convert the zero_extend_vector_inreg into a mask and constant fold it with the AND.
Differential Revision: https://reviews.llvm.org/D113985
…eScalarizeScalableVector When getTypeConversion returns TypeScalarizeScalableVector we were sometimes returning a non-simple type from getTypeLegalizationCost. However, many callers depend upon this being a simple type and will crash if not. This patch changes getTypeLegalizationCost to ensure that we always a return sensible simple VT. If the vector type contains unusual integer types, e.g. <vscale x 2 x i3>, then we just set the type to MVT::i64 as a reasonable default. A test has been added here that demonstrates the vectoriser can correctly calculate the cost of vectorising a "zext i3 to i64" instruction with a VF=vscale x 1: Transforms/LoopVectorize/AArch64/sve-inductions-unusual-types.ll Differential Revision: https://reviews.llvm.org/D113777
There was some confusion during the discussion of a patch as to whether `any` can be used to blast an attribute with no subject list onto basically everything in a program by not specifying a subrule. This patch adds documentation and tests to make it clear that this situation is not supported and will be diagnosed.
If possible fold fneg into instruction above if users cannot fold mods and we know it will decrease instruction count. Follows same logic as SDAG combiner in choosing opportunities to combine. Differential Revision: https://reviews.llvm.org/D112827
Instructions being tested were accidentally left dead.
Differential Revision: https://reviews.llvm.org/D114011
Tsan pass does 2 optimizations based on presence of calls: 1. Don't emit function entry/exit callbacks if there are no calls and no memory accesses. 2. Combine read/write of the same variable if there are no intervening calls. However, all debug info is represented as CallInst as well and thus effectively disables these optimizations. Don't consider debug info calls as calls. Reviewed By: glider, melver Differential Revision: https://reviews.llvm.org/D114079
They don't seem to do anything useful in lsan. They are needed only if a tools needs to execute some custom logic during detach/join, or if it uses thread registry quarantine. Lsan does none of this. And if a tool cares then it would also need to intercept pthread_tryjoin_np and pthread_timedjoin_np, otherwise it will mess thread states. Fwiw, asan does not intercept these functions either. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D113920
memprof does not use user_id for anything, so don't pass it to ThreadCreate. Passing a random field of MemprofThread as user_id does not make much sense anyway. Depends on D113920. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D113921
asan does not use user_id for anything, so don't pass it to ThreadCreate. Passing a random uninitialized field of AsanThread as user_id does not make much sense anyway. Depends on D113921. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D113922
The overload shouldSuppressDiagnostic seems unnecessary, and it is only used in clangd. This patch removes it and use the real one (suppression diagnostics are discarded in clangd at the moment). Fixes clangd/clangd#929 Differential Revision: https://reviews.llvm.org/D113999
Cleanup of clang-tidy findings: removing "else" after a return statement to improve readability of the code. This patch was created by applying the clang-tidy fixes automatically. Differential Revision: https://reviews.llvm.org/D113892
Replace filenames, variable names, check prefixes uses of blacklist with ignore list. Reviewed By: jkorous Differential Revision: https://reviews.llvm.org/D113211
|
/summary:run |
Use patterns for block names instead of fixed names. Remove checks for dead function.
vmaksimo
added
the
disable-lint
|
/summary:run |
vmaksimo
added a commit
to vmaksimo/llvm-test-suite
that referenced
this pull request
Nov 23, 2021
…llvm#4993 This should be reverted once the tests are fixed.
vmaksimo
requested review from
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
elizabethandrews,
hchilama,
mdtoguchi,
premanandrao and
smanna12
as code owners
|
Note: temporarily disabled 3 test-suite tests in intel/llvm-test-suite#580 |
vladimirlaz
pushed a commit
to intel/llvm-test-suite
that referenced
this pull request
Nov 24, 2021
|
/merge |
bb-sycl
approved these changes
Nov 24, 2021
|
Wed Nov 24 16:46:13 UTC 2021 --- Start to merge the commit into sycl branch. It will take several minutes. |
|
Wed Nov 24 16:49:23 UTC 2021 --- Merge the branch in this PR to base automatically. Will close the PR later. |
aelovikov-intel
pushed a commit
to aelovikov-intel/llvm
that referenced
this pull request
Mar 27, 2023
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@0f652d8f527f
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@05e183d