Addressed comments.

In D98041#2645874, @silvas wrote:

It looks like this patch simply moved std.dim to memref.dim, without doing the "splitting" which we had discussed. I now have code that only operates on tensors that is needing to pull in the memref dialect just for this. Can you split memref.dim into tensor.dim for the tensor case?

Addressed comments.

Adressed comments.

Removed corresponding ops in std dialect and adapted test cases.
Addressed comments.

Addressed comments.

Addressed comments.

Addressed comments.
Changed default max rank to 1 instead of 2 and changed condition to less or equal.
This way is more intuitive.

Addressed comments.
Introduce transformation if the alloc operands are RankOps.

In D90675#2393152, @vinograd47 wrote:

Hello! It looks like this documentation is a bit outdated. For example, setResultConversionKind method was removed and replaced with separate pass (see https://github.com/llvm/llvm-project/commit/f7bc56826616814a656866fd50e90a35a8e461eb). Is there any plans to update this documentation?

Addressed comments

Addressed comments.

Addressed comments.

Addressed comments.

Changed check to exclude automatic allocation scope resources.

Changed from a specialized MemRefCastOp version to a more general ViewLikeOpInterface version.
Adapt test case, since MemRefCastOp is currently not a ViewLikeOp.

Updated commit message and added a short summary.

@rriddle I've tried to come up with a minimal example including a new dialect. However, the issue does not occur in simple cases on our testing machines. The easiest way to dive into this issue would be to move line 728 in LowerGPUOpsToNNVMOps.cc to 750:

@mehdi_amini I fully get your point and I totally agree that we should not hide underlying bugs. However, you can argue as soon as two pattern matchers have the same benefit their ordering will be undefinied. In this case, the only possible solution you have, is to change the pattern matcher benefit.
@herhut We follow your arguments that we should unbreak the build on Windows asap. As mentioned above, this does not solve the general non-determinism issue. However, even if the ordering would be deterministic, we should not rely on intrinsic magic that might be easily broken by another commit in the future.

We built the project on a Windows machine and were able to reproduce the failed test. We figured out that the tests are right, but the error was caused by a non-deterministic pattern rewriter step. We fixed the issue in another PR: https://reviews.llvm.org/D73713.
This fix should work on all platforms (Windows/Linux).

Fixed test cases and format issues.

Fixed clang format issue.

Renamed BinaryIntrinsicOp to BinarySameArgsIntrinsicOp.
Renamed TernaryIntrinsicOp to TernarySameArgsIntrinsicOp.