Device cts fixes #1
Closed
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
Support LLVM::StackSaveOp and LLVM::StackRestoreOp in the LLVM dialect inliner in MLIR. Inserts new LLVM::StackSaveOp and LLVM::StackRestoreOp intrinsics when dynamic allocas are detected in the inlined blocks. This may result in multiple saves/restores in the same block if some are already present in the caller, which is legal IR, but is cleaned up in LLVM. There is not yet a canonicalization pattern for this on LLVM dialect in MLIR. Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D148011
…tions The previous patch, D135564, was too conservative to avoid store interleave for streaming-compatible functions/mode. In this patch, we allow using the interleave store but using scalable vector. Reviewed By: david-arm, sdesmalen Differential Revision: https://reviews.llvm.org/D147040
This renames the experimental "cluster_group" as "fixed_size_group". We needed to reclaim the name for future extension purposes. --------- Signed-off-by: James Brodman <[email protected]>
This was out of date and the link to the lldb tag will always be up to date.
This reverts commit 27c4777. It created problems for testing on Gentoo, see: https://reviews.llvm.org/rG27c4777f41d2ab204c1cf84ff1cccd5ba41354da#1190273 Reverted until https://reviews.llvm.org/D147652 has been landed.
It seems that existing logic is too strict about latch block exit count. It is required to be computable, however it is not used in any computations, and effectively the only thing it is used for is to get the type of computed exit count. Sometimes the exit count for latch block is not known, but the loop is still finite because of other exits, and safe bounds are still computable. In this case, we miss an opportunity to apply IRCE. We could instead use a more relaxed version - max symbolic exit count, which, if exists, is enough to say that the loop is finite, and its type should be good enough. There is a subtlety with type: we do not support latch count type wider than range check type. Because of that, we want to have the narrowest type available. So if it can be computed from latch block immediately, take it. Otherwise, take whatever whole loop provides and hope that it's type isn't too wide. Differential Revision: https://reviews.llvm.org/D147910 Reviewed By: danilaml
…am.h When this header now is a fully regular header within the src tree, give it a more regular name. Differential Revision: https://reviews.llvm.org/D148072
…ack size This passes the same option that was added for MSVC builds in fb5a24b in the corresponding mingw form too. This fixes the BVGraph tests in the sanitizer unit tests. Differential Revision: https://reviews.llvm.org/D148132
In mingw mode on x86, long doubles are 80 bit - while MSVC mode uses long doubles that are equal to regular doubles (on all architectures). In the case of this formatting function, we're calling a MS CRT provided printf function which interprets long doubles as 64 bit. Since the long doubles are equal to regular doubles on all MSVC platforms, just use regular double formatting. For MSVC environments there's no difference, but for mingw environments, this avoids the ambiguity. Differential Revision: https://reviews.llvm.org/D148133
…VC target This test uses lots of lld-link specific linker options that don't work as such in mingw command lines. Differential Revision: https://reviews.llvm.org/D148168
…ted on mingw Mingw toolchains always end up referencing the malloc symbol due to the CRT startup files. Differential Revision: https://reviews.llvm.org/D148166
… mingw mode This parameter isn't essential for the execution of this test, so just skip it when running tests in mingw mode. Differential Revision: https://reviews.llvm.org/D148165
This fixes libunwind_01.pass.cpp for x86_64 Windows. Differential Revision: https://reviews.llvm.org/D147635
When we initialize the UnwindCursor (unw_cursor_t) based on an existing Registers object (unw_context_t), we only initialize a subset of the class. Fill the struct properly for the current thread with RtlCaptureContext, followed by overwriting of the subset of registers that we do have available in the Registers class. One might think that it's enough to initialize specifically the registers that we signal availability for with ContextFlags, however in practice, that's not enough. This fixes crashes when restoring the context via RtlRestoreContext (via UnwindCursor::jumpto), via __unw_resume. Differential Revision: https://reviews.llvm.org/D147636
… with -nodefaultlibs on mingw targets The clang-cl/MSVC case is handled above, thus consider win32 && !is_msvc to be mingw. This matches the list of libraries passed by e.g. the libcxx build, when using -nodefaultlibs. Differential Revision: https://reviews.llvm.org/D147647
The purpose of this patch and follow-on patches is to ensure that AttributeCommonInfos always have a syntax that is appropriate for their kind (i.e. that it matches one of the entries in Attr.td). The attribute-specific Create and CreateImplicit methods had four overloads, based on their tail arguments: (1) no extra arguments (2) an AttributeCommonInfo (3) a SourceRange (4) a SourceRange, a syntax, and (where necessary) a spelling When (4) had a spelling argument, it defaulted to SpellingNotCalculated. One disadvantage of this was that (1) and (3) zero-initialized the syntax field of the AttributeCommonInfo, which corresponds to AS_GNU. But AS_GNU isn't always listed as a possibility in Attr.td. This patch therefore removes (1) and (3) and instead provides the same functionality using default arguments on (4) (a bit like the existing default argument for the spelling). The default syntax is taken from the attribute's first valid spelling. Doing that raises the question: what should happen for attributes like AlignNatural and CUDAInvalidTarget that are only ever created implicitly, and so have no source-code manifestation at all? The patch adds a new AS_Implicit "syntax" for that case. The patch also removes the syntax argument for these attributes, since the syntax must always be AS_Implicit. For similar reasons, the patch removes the syntax argument if there is exactly one valid spelling. Doing this means that AttributeCommonInfo no longer needs the single-argument constructors. It is always given a syntax instead. Differential Revision: https://reviews.llvm.org/D148101
This patch adds an extra AttributeCommonInfo::Form constructor for keywords, represented by their TokenKind. This isn't a win on its own, but it helps with later patches. No functional change intended. Differential Revision: https://reviews.llvm.org/D148103
This patch adds static functions for constructing most AttributeCommonInfo::Forms. Direct construction is only retained where all fields (currently the syntax and spelling) are specified explicitly. This is a wash on its own. The purpose is to allow extra fields to be added to Form without disrupting all callers. In particular, it allows extra information to be stored about keywords without affecting non-keyword uses. No functional change intended. Differential Revision: https://reviews.llvm.org/D148104
When constructing an attribute, the syntactic form was specified using two arguments: an attribute-independent syntax type and an attribute-specific spelling index. This patch replaces them with a single argument. In most cases, that's done using a new Form class that combines the syntax and spelling into a single object. This has the minor benefit of removing a couple of constructors. But the main purpose is to allow additional information to be stored as well, beyond just the syntax and spelling enums. In the case of the attribute-specific Create and CreateImplicit functions, the patch instead uses the attribute-specific spelling enum. This helps to ensure that the syntax and spelling are consistent with each other and with the Attr.td definition. If a Create or CreateImplicit caller specified a syntax and a spelling, the patch drops the syntax argument and keeps the spelling. If the caller instead specified only a syntax (so that the spelling was SpellingNotCalculated), the patch simply drops the syntax argument. There were two cases of the latter: TargetVersion and Weak. TargetVersionAttrs were created with GNU syntax, which matches their definition in Attr.td, but which is also the default. WeakAttrs were created with Pragma syntax, which does not match their definition in Attr.td. Dropping the argument switches them to AS_GNU too (to match [GCC<"weak">]). Differential Revision: https://reviews.llvm.org/D148102
AttributeCommonInfo::isAlignasAttribute() was used in one place: isCXX11Attribute(). The intention was for isAlignasAttribute() to return true for the C++ alignas keyword. However, as a FIXME noted, the function also returned true for the C _Alignas keyword. This meant that isCXX11Attribute() returned true for _Alignas as well as for alignas. AttributeCommonInfos are now always constructed with an AttributeCommonInfo::Form. We can use that Form to convey whether a keyword is alignas or not. The patch uses 1 bit of an 8-bit hole in the current layout of AttributeCommonInfo. This might not be the best long-term design, but it should be easy to adapt the layout if necessary (that is, if other uses are found for the spare bits). I don't know of a way of testing this (other than grep -c FIXME) Differential Revision: https://reviews.llvm.org/D148105
Following a suggestion from Erich in https://reviews.llvm.org/D148101, this patch bumps AS_GNU to 1 so that syntax 0 is invalid. It also asserts that the syntax is in range. Differential Revision: https://reviews.llvm.org/D148148
Repeatedly calling getName adds some overhead, which can be easily avoided by querying the name just once per function. The improvements are rather small (~0.5% back-end time in a compile-time optimized setting), but also very easy to achieve. Note that getting the name should be entirely avoidable in the common case, but would require more substantial changes. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D148145
Signed-off-by: Jun Zhang <[email protected]>
We can eliminate the or operation based on the predicate and the relation between OrC and C. sge: X | OrC s>= C --> X s>= 0 iff OrC s>= C s>= 0 sgt: X | OrC s> C --> X s>= 0 iff OrC s> C s>= 0 sle: X | OrC s<= C --> X s< 0 iff OrC s> C s>= 0 slt: X | OrC s< C --> X s< 0 iff OrC s>= C s>= 0 Alive2 links: sge: https://alive2.llvm.org/ce/z/W-6FHE sgt: https://alive2.llvm.org/ce/z/TKK2yJ sle: https://alive2.llvm.org/ce/z/vURQGM slt: https://alive2.llvm.org/ce/z/JAsVfw Related issue: llvm/llvm-project#61538 Signed-off-by: Jun Zhang <[email protected]> Differential Revision: https://reviews.llvm.org/D147597
Similar to the getArithmeticReductionCost / getExtendedReductionCost calls (which really don't need to use std::optional<>). This will be necessary to correct recognize fast/nnan fmax/fmul reductions which can avoid nan handling - which will allow us to remove the fmax/fmin special case in X86TTIImpl::getMinMaxCost and use getIntrinsicInstrCost like we do for integer reductions (63c3895). Differential Revision: https://reviews.llvm.org/D148149
This PR introduces the `BrStack` member to store the info about `loop`, `block`, `if` and `try`. It can check whether `br` immediate number out of range. Reviewed By: aheejin Differential Revision: https://reviews.llvm.org/D148054
They had previously not followed the best practices; I must have commited these in a rush. In particular, they used hard-coded SSA names instead of patterns. This patch changes that, uses CHECK-DAG more instead of CHECK-NEXT, and makes all function names unique. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D148012
Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
intel#8601 intel#8993 Signed-off-by: Jaime Arteaga <[email protected]>
intel#8996 Signed-off-by: Jaime Arteaga <[email protected]>
intel#8769 Signed-off-by: Jaime Arteaga <[email protected]>
intel#8848 Signed-off-by: Jaime Arteaga <[email protected]>
intel#9052 Signed-off-by: Jaime Arteaga <[email protected]>
intel#8763 Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
https://github.com/intel/llvm/pull/8603/files Signed-off-by: Jaime Arteaga <[email protected]>
intel#9094 Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
intel#9109 Signed-off-by: Jaime Arteaga <[email protected]>
intel#9067 Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Brandon Yates <[email protected]>
|
didn't work right, i'll try again |
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.
No description provided.