LLVM and SPIRV-LLVM-Translator pulldown (WW38) #2468
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
Asan does not use metadata with primary allocators. It should match AP64::kMetadataSize whic is 0. Depends on D86917. Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D86919
It is used by clusterfuzz (google/clusterfuzz#2009) and having this compatibility option for a while can help they do bisection with the latest llvm-symbolizer. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D87067
References to different declarations of the same entity aren't different values, so shouldn't have different representations.
Previously we had two overloads where the only real difference beyond parameter order was whether a reference parameter is const, where one overload treated the reference parameter as an in-parameter and the other treated it as an out-parameter!
- When an operand is changed into an immediate value or like, ensure their target flags being cleared or set properly. Differential Revision: https://reviews.llvm.org/D87109
This adds the size to forward declared class DITypes, if the size is known. Fixes an issue where we determine whether to emit fragments based on the type size, so fragments would sometimes be incorrectly emitted if there was no size. Bug: https://bugs.llvm.org/show_bug.cgi?id=47338 Differential Revision: https://reviews.llvm.org/D87062
Simplify:
defined(__ARM_DWARF_EH__) || !defined(__arm__)
to:
!defined(_LIBUNWIND_ARM_EHABI)
A later patch benefits from the simplicity. This change will result in
the two DWARF macros being defined when __USING_SJLJ_EXCEPTIONS__ is
defined, but:
* That's already the case with the __APPLE__ and _WIN32 clauses.
* That's also already the case with other architectures.
* With __USING_SJLJ_EXCEPTIONS__, most of the unwinder is #ifdef'ed
away.
Generally, when __USING_SJLJ_EXCEPTIONS__ is defined, most of the
libunwind code is removed by the preprocessor. e.g. None of the hpp
files are included, and almost all of the .c and .cpp files are defined
away, except in Unwind-sjlj.c. Unwind_AppleExtras.cpp is an exception
because it includes two hpp files, which it doesn't use. Remove the
unneeded includes for consistency with the general rule.
Reviewed By: steven_wu
Differential Revision: https://reviews.llvm.org/D86767
The optimization in ExpandIntOp_UINT_TO_FP was removed in D72728 in January 2020.
This has not used tied operands for a long time.
std::length_error needs stdexcept.
New name better represents the state of chunk.
The new feature in GitHub called 'GitHub Codespaces' generates a pythonenv3.8 directory in the root level of the llvm-project git checkout. So I am adding that directory to the .gitignore. See the following for more info: https://github.com/features/codespaces Differential Revision: https://reviews.llvm.org/D86846
When allowed, use 32-bit indices rather than 64-bit indices in the SIMD computation of masks. This runs up to 2x and 4x faster on a number of AVX2 and AVX512 microbenchmarks. Reviewed By: bkramer Differential Revision: https://reviews.llvm.org/D87116
The implementation is not fully standards compliant in the sense that errno is not set on error, and floating point exceptions are not raised. Subnormal range and normal range are tested separately in the tests. Reviewed By: lntue Differential Revision: https://reviews.llvm.org/D86666
Address post-review comment.
…ions Historically, the operations in the MLIR's LLVM dialect only checked that the operand are of LLVM dialect type without more detailed constraints. This was due to LLVM dialect types wrapping LLVM IR types and having clunky verification methods. With the new first-class modeling, it is possible to define type constraints similarly to other dialects and use them to enforce some correctness rules in verifiers instead of having LLVM assert during translation to LLVM IR. This hardening discovered several issues where MLIR was producing LLVM dialect operations that cannot exist in LLVM IR. Depends On D85900 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85901
This patch updates MemCpyOpt to preserve MemorySSA. It uses the MemoryDef at the insertion point of the builder and inserts the new def after that def. In some cases, we just modify a memory instruction. In that case, get the defining access, then remove the memory access and add a new one. If the defining access is in a different block, insert a new def at the beginning of the current block, otherwise after the defining access. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D86651
Some tests depend on DSE removing dead instructions unrelated to any memory optimization. That's not really DSE's job, remove it.
I have fixed up some more ElementCount/TypeSize related warnings in the following tests: CodeGen/AArch64/sve-split-extract-elt.ll CodeGen/AArch64/sve-split-insert-elt.ll In SelectionDAG::CreateStackTemporary we were relying upon the implicit cast from TypeSize -> uint64_t when calling MachineFrameInfo::CreateStackObject. I've fixed this by passing in the known minimum size instead, which I believe is fine because the associated stack id indicates whether this is a scalable object or not. I've also fixed up a case in TargetLowering::SimplifyDemandedBits when extracting a vector element from a scalable vector. The result is a scalar, hence it wasn't caught at the start of the function. If the vector is scalable we just bail out for now. Differential Revision: https://reviews.llvm.org/D86431
…_test This is one of the most expensive tests and runs for nearly half a minute on my machine. Beside this test just doing a lot of work by iterating 15k times on one ValueObject (which seems to be the point), it also runs this for every debug info variant which doesn't seem relevant to just iterating ValueObject. This marks it as no_debug_info_test to only run one debug info variation and cut down the runtime to around 7 seconds on my machine.
This change implements pragma STDC FENV_ROUND, which is introduced by the extension to standard (TS 18661-1). The pragma is implemented only in frontend, it sets apprpriate state of FPOptions stored in Sema. Use of these bits in constant evaluation adn/or code generator is not in the scope of this change. Parser issues warning on unsuppored pragma when it encounteres pragma STDC FENV_ROUND, however it makes syntax checks and updates Sema state as if the pragma were supported. Primary purpose of the partial implementation is to facilitate development of non-default floating poin environment. Previously a developer cannot set non-default rounding mode in sources, this mades preparing tests for say constant evaluation substantially complicated. Differential Revision: https://reviews.llvm.org/D86921
…rict qualifier in C++ The "restrict" keyword is illegal in C++, however, many libc implementations use the "__restrict" compiler intrinsic in functions prototypes. The "__restrict" keyword qualifies a type as a restricted type even in C++. In case of any non-C99 languages, we don't want to match based on the restrict qualifier because we cannot know if the given libc implementation qualifies the paramter type or not. Differential Revision: https://reviews.llvm.org/D87097
This makes the interface cleaner and slightly improves messages reported. Differential revision: https://reviews.llvm.org/D87086
This is a follow-up suggested in D86420 - if we have a pair of stores in inverted order for the target endian, we can rotate the source bits into place. The "be_i64_to_i16_order" test shows a limitation of the current function (which might be avoided if we integrate this function with the other cases in mergeConsecutiveStores). In the earlier "be_i64_to_i16" test, we skip the first 2 stores because we do not match the full set as consecutive or rotate-able, but then we reach the last 2 stores and see that they are an inverted pair of 16-bit stores. The "be_i64_to_i16_order" test alters the program order of the stores, so we miss matching the sub-pattern. Differential Revision: https://reviews.llvm.org/D87112
… use for i64 on 32-bit targets. Differential Revision: https://reviews.llvm.org/D87214
This was supposed to be an NFC cleanup, but there's a real logic difference (did not drop 'nsw') visible in some tests in addition to an efficiency improvement. This is because in the case where we have 2 GEPs, the code was *always* swapping the operands and negating the result. But if we have 2 GEPs, we should *never* need swapping/negation AFAICT. This is part of improving flags propagation noticed with PR47430.
Currently auxiliary cmake options are loacted after log options. Looks like auxiliary options are not taken into account for this reason.
CONFLICT (modify/delete): clang/include/clang/Frontend/DependencyOutputOptions.def deleted in 8d2d0e8 and modified in HEAD. Version HEAD of clang/include/clang/Frontend/DependencyOutputOptions.def left in tree.
Add llvm.experimental.constrained.* intrinsic support, namely : fadd, fsub, fmul, fdiv, frem, fma, fmulladd, fptoui, fptosi, uitofp, sitofp, fptrunc, fpext, fcmp, fcmps. These intrinsics are not actually supported in SPIR-V, but just being emulated via existing functionality with loss of "constrained" semantic Signed-off-by: amochalo <[email protected]>
… extensions (intel#714) This patch addresses [comment][1] If the appropriate extension for arbitrary precision instruction is not enabled, invalid IR will be produced. Report an error in this case. [1]: KhronosGroup/SPIRV-LLVM-Translator#653 (comment)
Replaced nullptr with an empty string
Replaced usages of "VectorType::getNumElements" with "FixedVectorType::getNumElements" Signed-off-by: amochalo <[email protected]>
This reverts commit 0730882.
vladimirlaz
requested review from
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
elizabethandrews,
Fznamznon,
mdtoguchi and
premanandrao
as code owners
|
/summary:run |
|
The test failing is Summary run is flaky. |
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@8b30067
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@48c6ff6