- User Since
- Apr 12 2020, 10:42 PM (33 w, 3 d)
Tue, Nov 17
@rriddle Thanks for reviewing many times! I don't have commit access. Could you commit this patch if you don't have any other comments?
Sun, Nov 15
Hi, @rriddle, do you have any comments on this patch?
Tue, Nov 10
Rebased and reflected comments.
Nov 1 2020
Oct 31 2020
Updated comments and inserted assert.
Oct 30 2020
Use ulittle for eidian conversion.
Oct 28 2020
Reflected the comment.
Oct 27 2020
@rriddle Thanks for your review. I don't have commit access. If you don't have other comments, could you commit this patch?
Avoid warning message.
Avoid warning in assert().
Oct 26 2020
@rriddle Thanks for your comments. I answered some of the comments.
Reflected comments and rebased.
Oct 20 2020
Removed unnecessary headers.
Moved the convEndianBE into DenseIntOrFPElementsAttr class and removed EndianUtilities.
@mehdi_amini Thanks for your review! I reflected all of your comments.
Reflected @mehdi_amini's comments.
Oct 19 2020
Implemented the conversion from LE to BE in AttributeParser and from BE to LE in AsmPrinter
, assuming that HEX in dense.attr is always LE.
Oct 5 2020
Rebased and fixed a comment.
Updated test case to include two operation results.
Reflected comments and rebased.
Oct 2 2020
@bondhugula @avarmapml I found the results(returend memref) of normalizable operation were not normalized by --normalize-memrefs.
In test case, %1 was not normalized. This patch fixes it.
%1 = "test.op_norm_ret"(%arg0, %arg1) : (memref<1x32768xf32>, memref<1x16x14x14xf32, #map1>) -> (memref<1x16x14x14xf32, #map1>)
Fix to remove warning message (newOp -> *newOp)
Sep 25 2020
Sep 23 2020
@bondhugula It seems there is no additional comments. Could you commit also this patch?
glad to see that the traits make such changes easy...
Yes. The traits are very useful. We might need to add them in other ops depending on use-case, but it is easy.
Reflected the comment about map, and rebased
When we use load and store ops like the test in this patch, the --normalize-memrefs does not work. This patch fix it by adding MemRefsNormalizable trait in load and store ops.
If we can use affine.load and affine.store in this test, the normalization works, but sometimes affine.load can not be used. In the case, we need to use std.load.
Sep 22 2020
Sep 18 2020
Sep 17 2020
Updated comments and rename test func
Sep 16 2020
Fixed comments and format
Sorry, I may did wrong operaton... I will fix this.
Rebased and rephrased the comment.
Added test and comments, and renamee variables to reflrect comments
This bug was discussed here https://llvm.discourse.group/t/memrefs-and-maps-for-tiling/1279/21
Following example failed because spv.EntryPoint "GLCompute" @empty can't be casted to CallOp. I created the example to reproduce errors happened in my code which uses EntryPoint op of my own dialect. This example may not be practical, but this reproduced the same error with my code.
Sep 14 2020
Sep 10 2020
Sep 8 2020
Thanks. I checked the source code. The dense attribute with hex data is parsed here https://github.com/llvm/llvm-project/blob/master/mlir/lib/Parser/AttributeParser.cpp#L682-L684
If we can assume the hex data is always little-endian, it can be converted here, but we can't assume that. So, my understanding is that the hex data of dense-elements-hex.mlir should be generated depending on the endianness. Is this possible? I'm looking for similar examples.
Sep 6 2020
Aug 31 2020
Hi, I'm looking for reviewers for this patch. This patch is old. So, I need to update, but I would like to hear your comments about how we should pass this test on big-endian machines. Since current test includes HEX of little endian, this test fails on big-endian machines.
@jpienaar, @ftynse, @mehdi_amini, @rriddle @Smit You were reviewers for patches including this test before. Could you give me your comments?
Jul 21 2020
Jul 19 2020
@bondhugula Thanks for your review! I reflected your comments.
I think I don't have right to land this patch. Could you land this if you don't have additional comments?
Jul 14 2020
Change CHECK to CHECK-NEXT
Thanks for your comments! I updated.
Remove redundant code
Jul 13 2020
Jul 12 2020
Jun 29 2020
@rriddle Hi, is it possible to give me your comments about this patch? I'm asking because you were a reviewer of the previous patch including this file.
Jun 10 2020
Reflect reviewer's comments.
Jun 2 2020
Could anyone be a reviewer of this patch? This patch is about one of the MLIR test (dense-elements-hex.mlir).
May 28 2020
Rebased with master
Fixed "No newline at end of file"
May 26 2020
May 20 2020
Fixed variable name to meet camelBack style
May 19 2020
Changed getHostCPUName() part to reflect the comment.
May 18 2020
My wrong operation(submission) may add LLDB tag on this patch.
Thanks for the review! I changed the variable name to camelBack
- [NFC] Replace MaybeAlign with Align in TargetTransformInfo.
- [mlir][SystemZ] Fix incompatible datalayout in SystemZ
[mlir][SystemZ] Fix incompatible datalayout in SystemZ
Without this patch, following tests fail in SystemZ(z14)
MLIR :: mlir-cpu-runner/linalg_integration_test.mlir MLIR :: mlir-cpu-runner/sgemm_naive_codegen.mlir MLIR :: mlir-cpu-runner/simple.mlir MLIR :: mlir-cpu-runner/unranked_memref.mlir MLIR :: mlir-cpu-runner/utils.mlir
Error message is as follows.
Failure value returned from cantFail wrapped call Added modules have incompatible data layouts: E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64 (module) vs E-m:e-i1:8:16-i8:8:16-i64:6\ 4-f128:64-v128:64-a:8:16-n32:64 (jit)
Apr 30 2020
@rriddle Is this patch ready for commit? If so, could you help to commit this? I think I don't have write access to the repository.