Johannes Reifferscheid

> [tf_library rule](https://github.com/tensorflow/tensorflow/blob/04ea1a50df9c8bd11cf740b20139ab7a7d18c349/tensorflow/compiler/aot/tfcompile.bzl#L450) should have `mlir_components` set to "HloLowering". Or alternatively, depend on the [implicitly defined MLIR library](https://github.com/tensorflow/tensorflow/blob/04ea1a50df9c8bd11cf740b20139ab7a7d18c349/tensorflow/compiler/aot/tfcompile.bzl#L537) (name + '_mlir' suffix).

Thanks for your PR and sorry for the delay, I didn't see this. I just took a quick look and have a few comments: - We need to make sure...

Thanks! I just noticed the atomic issue as well. I'll fix this today. Looking at this PR now.

Thank you for the updates. I need to think about the design of this a bit. I don't think we can implement vectorization in MLIR like this. If we can't...

We're about to replace the LLVM emitters, so I don't think we should invest significant effort into making changes to them at this point. For MLIR, how about this: -...

Can you explain in a bit more detail what you mean by "rotate iter args"? Also, I recommend not spending any more time on the non-MLIR emitters. They're not going...

Ah! Great idea. Can you revert all the legacy emitter stuff from this PR and move the performance model stuff to a separate PR to be landed first? I think...

Yeah, we've run into that issue a few times. It's particularly bad with types

I'm about to add exactly such an argument to ReductionInfo::Create (bool for_mlir). Feel free to just ignore the legacy emitter for now, I think I'll probably land this change today...

> I'm about to add exactly such an argument to ReductionInfo::Create (bool for_mlir). Feel free to just ignore the legacy emitter for now, I think I'll probably land this change...