llvmspirv pulldown #9479
Closed
llvmspirv pulldown #9479
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
The code is doing the optimization: `((a | c1) << c2)` ==> `(a << c2) + (c1 << c2)` But this is only valid if `a` and `c1` have no common bits being set. Differential Revision: https://reviews.llvm.org/D150246
The revision adds basic timing to the mlir-translate tool. Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D150434
This patch consumes the EntryValueObjects in a MachineFunction's table, using them to emit the appropriate debug information for these variables. Depends on D149880 Differential Revision: https://reviews.llvm.org/D149881
Most of the code changed here dates back to 2010, when LLDB was first introduced upstream, as such it benefits from a slight cleanup. The method "dump" is not used anywhere nor is it tested, so this commit removes it. The "findRanges" method returns a boolean which is never checked and indicates whether the method found anything/assigned a range map to the out parameter. This commit folds the out parameter into the return type of the method. A handful of typedefs were also never used and therefore removed. Differential Revision: https://reviews.llvm.org/D150363
The TrackingListener was unnecessarily strict. Existing ops are now allowed when updating payload ops mappings due to `replaceOp` in the TrackingListener. Differential Revision: https://reviews.llvm.org/D150429
…hen call stack frame extension is invoked When the stack frame extension routine is used, the contents of r3 is overwritten. However, if r3 is live in the prologue (ie. one of the function's parameters resides in r3), it needs to be saved. We save r3 in r0 if r0 is available (ie. r0 is not used as temporary storage for r4), and in the corresponding stack slot for the third parameter otherwise. Differential Revision: https://reviews.llvm.org/D150332 Reviewed By: uweigand
The newly added compiler_pop_stack_no_memoperands has no memory operands on the memory instructions but accesses the same locations as compiler_pop_stack. At the moment, accesses to the stack are missed by shrink-wrapping. Test case for the issue pointed out by @jpenix-quic in D149668 post-commit.
This change adds the following three operations and unit tests for them: - conv_3d_ncdhw_fcdhw - depthwise_conv_1d_ncw_cw - depthwise_conv_3d_ncdhw_cdhw Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D150054
- Added missing TensorTransformOps to the Transform doc - Added missing AMDGPUPasses to the Passes doc - Place `async dialect` in alphabetical order in the Passes doc Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D150341
This reverts commit 8d657c4. Reverts it due to the regression reported in D150068.
…X3 to VEX2 1. Share code `optimizeInstFromVEX3ToVEX2` with MCInstLower 2. Move the code of optimization for shift/rotate to a separate file 3. Since the function is shared, a side effect is that more encoding optimizations are done on the Asmparser side. Considering we already use reverse-encoding for optimization in AsmParser before this patch, I believe the change is positive and expected. This is a reland of D150068 with the fix D150440.
As pointed out by @jpenix-quic in D149668 post-commit, machine instructions without memory operands need to be treated conservatively.
…sic memcpy. With this change, more `memref.copy` will be lowered to the efficient `memcpy`. For example, ``` memref.copy %subview, %alloc : memref<1x576xf32, strided<[704, 1]>> to memref<1x576xf32> ``` Differential Revision: https://reviews.llvm.org/D150448
Change-Id: I608f14ac3a504cc668f93f130a17dea3950fa554
Also some simplifications: * `outputBufferOperands` was unused. * The condition that the number of operands equals the number of inputs plus the number of inits seemed vacuously true (?). Differential Revision: https://reviews.llvm.org/D150376
The financial cost of the network I/O for the Clang install artifacts is quite significant. afd3478 improved this by creating tarballs. This commit improves the tarball by using xz compression instead of gzip. This option is the slowest, but gives the smallest size. size time time (compression) (decompression) gzip 51 M 7 s 1.2 s bz2 44 M 17 s 5.8 s xz 33 M 76 s 3.1 s Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D150062
These tests should have added -std=c++23 instead of replacing -std=c++2b in D149553. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D150063
The newer formatters for (tuple, vector<bool>::reference) specify the formatter's parse and format member function. This signature is slightly different from the signature for existing formatters. Adapt the existing formatters to the new style. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D150034
Differential Revision: https://reviews.llvm.org/D149986
This commit implements IRTranslator lowering of dbg.declare intrinsics targeting swiftasync Arguments, by putting them in the MachineFunction's table of variables whose location doesn't change throughout the function. Depends on D149881 Differential Revision: https://reviews.llvm.org/D149882
While pointers in address space 7 (128 bit rsrc + 32 bit offset) should be rewritten out of the code before IR translation on AMDGPU, higher-level analyses may still call MVT getPointerTy() and the like on the target machine. Currently, since there is no MVT::i160, this operation ends up causing crashes. The changes to the data layout that caused such crashes were D149776. This patch causes getPointerTy() to return the type MVT::v5i32 and getPointerMemTy() to be MVT::v8i32. These are accurate types, but mean that we can't use vectors of address space 7 pointers during codegen. This is mostly OK, since vectors of buffers aren't supported in LPC anyway, but it's a noticable limitation. Potential alternative solutions include adjusting getPointerTy() to return an EVT or adding MVT::i160 and MVT::i256, both of which are rather disruptive to the rest of the compiler. Reviewed By: foad Differential Revision: https://reviews.llvm.org/D150002
This commit implements SelectionDAG lowering of dbg.declare intrinsics targeting swiftasync Arguments, by putting them in the MachineFunction's table of variables whose location doesn't change throughout the function. Depends on D149882 Differential Revision: https://reviews.llvm.org/D149883
…lh/mul_lohi are not available. Correct the legality of i32 mul_lohi on AArch64. Previously, AArch64 incorrectly reported i32 mul_lohi as Legal. This allowed BuildUDIV/SDIV to use them. A later DAGCombiner would replace them with MULHS/MULHU because only the high half was used. This conversion does not check the legality of MULHS/MULHU under the assumption that LegalizeDAG can turn it back into MUL_LOHI later. After they are converted to MULHS/MULHU, DAGCombine ran and saw that these operations aren't supported but an i64 MUL is. So they get converted to that plus a shift. Without this, LegalizeDAG would convert back MUL_LOHI and isel would fail to find a pattern. This patch teaches BuildUDIV/SDIV to create the wide mul and shift so that we can report the correct operation legality on AArch64. It also enables div by constant folding for more cases on VE. I don't know if VE wants this div by constant optimization or not. If they don't want it, they can use the isIntDivCheap hook to disable it. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D150333
Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D150414
Add llvm-mca tests for RISCV LMUL instruments to show that llvm-mca RISCV LMUL instruments work. Differential Revision: https://reviews.llvm.org/D149496
…epare While the original motivation for this patch (address space 7 on AMDGPU) has been reworked and is not presently planned to reach IR translation, the incorrect (by the spec) handling of index offset width in IR translation and CodeGenPrepare is likely to trip someone - possibly future AMD, since we have a p7:160:256:256:32 now, so we convert to the other API now. Reviewed By: aemerson, arsenm Differential Revision: https://reviews.llvm.org/D143526
This commit passed buildable tests in phabricator, but fails once committed. This reverts commit 1dedc96.
It was confusing to some contributors because it appeared in a prominent place on the Contibuting page.
Reviewed By: klausler Differential Revision: https://reviews.llvm.org/D150533
The temporary descriptor must be either Pointer or Allocatable, otherwise its memory will not be freed. Reviewed By: klausler Differential Revision: https://reviews.llvm.org/D150534
Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D150172
This reverts commit b049fc0. The wrong patch was landed.
A code-review comment to change a couple of CHECK to CHECK-NEXT that I forgot to apply prior to committing. Differential Revision: https://reviews.llvm.org/D150445
…rt of immediate context for deduction" (intel#13094) Updated test after 629170f
CONFLICT (content): Merge conflict in clang/test/CodeGenSYCL/field-annotate-addr-space.cpp CONFLICT (content): Merge conflict in clang/test/CodeGenSYCL/unique_stable_name.cpp
CONFLICT (content): Merge conflict in clang/lib/Frontend/CompilerInvocation.cpp
) Currently, we always convert SPIR-V bultins to globals for forward translation and to functions for reverse translation. I have a use case where I want to keep them as globals for reverse translation, so I added this mode. Implementations for both cases already existed, I just consolidated them and added the option. Signed-off-by: Sarnie, Nick <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@730eaf0
This target extension type is created here: https://github.com/intel/vc-intrinsics/blob/master/GenXIntrinsics/lib/GenXIntrinsics/GenXSPIRVWriterAdaptor.cpp#L245 As with other target extension types, reverse translation is not yet supported. Signed-off-by: Sarnie, Nick <[email protected]> Co-authored-by: Victor Mustya <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@60746d5
Currently only to DebugInfo/X86 Currently failing tests can be noticed by RUNx line Signed-off-by: Sidorov, Dmitry <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@772c7be
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.
-KOption for AIX.ranges::to):SkipPastparam fromgetValue(const ValueDecl &).Expr-o /dev/nulltest for Windowsdiv/remare safe to speculate"structin the declarationerrno-Loptions when compiling directly for AMDGPUiota_view's constructor's incorrect constraint--dump-sectionon COFF__AMDGCN_CUMODE__$prefix(x * (Pow2_Ceil(C1) - (1 << C0))) & C1->(-x << C0) & C1; NFC(x * (Pow2_Ceil(C1) - (1 << C0))) & C1->(-x << C0) & C1i1operands; PR62607isKnownNeverZeroandisKnownToBeAPowerOfTwocomputeKnownBitsifOpis not recognized byisKnownNeverZeroSkipPast::ReferenceThenPointer.export type X = Y