Updated for jpienaar@ comments

In D156362#4619838, @mehdi_amini wrote:

@rsuderman do you have some info on the original implementation (it was yours right?) and the change in numerics here?

Rebased.

Overall I would move these next to the other constant folders. Looking standing back they are all the same as the other layerwise folders and should be kept together. There is not much value is separating the reduction folders into a separate file. Once thats done I can approve and land.

I agree that this is the right decomposition. The original implementation matched this behavior as well, however it was reverted due to other parties requesting truncation of fp should include rounding. Approving so you can land, just be aware this may bring wider discussions.

Sorry for the delay

In D155645#4516004, @dcaballe wrote:

Thanks, Rob! I would like to know what @nicolasvasilache thinks, in case I'm missing something, but I think both linalg.matmul and vector.contract shouldn't allow inputs with different types at all. That should be something to check in the op verification and the proper conversion should happen up in the pipeline, when we generate the linalg.matmul op in first place. Does that make sense to you?

Updated to remove requirement change and instead update vectorization code

In D155645#4512893, @dcaballe wrote:

In D155645#4512836, @rsuderman wrote:

In D155645#4512578, @dcaballe wrote:

Hey Rob! Thanks for sending this patch.

E.g. i8 and i16 may accumulate into an i32 legally, despite not matching in bitwidth.

I think if that is the case, we should extend i8 to i16 first and then use an i16, i16 -> i32 contract. We have to keep the number of variants under control at this level of abstraction. Otherwise, the transformations and contract lowerings would have to deal with too many cases.
Would that work for your case?

Thanks,
Diego

So there is actually a slight problem with that. I used the i8 and i16 case for a simple example. The actual case I am encountering is f16 and bf16 which have lossy casting both ways. Happy to look into an alternate solution but none are coming to my mind.

Ha, that's interesting. I guess it's up to the framework to define what happens when we operate an f16 and bf16 (what is the direction of the conversion). It sounds like we want to disambiguate that as early as possible instead of rolling down the ball. That call would have to be made by specific spec in charge.

In D155645#4512578, @dcaballe wrote:

Hey Rob! Thanks for sending this patch.

E.g. i8 and i16 may accumulate into an i32 legally, despite not matching in bitwidth.

I think if that is the case, we should extend i8 to i16 first and then use an i16, i16 -> i32 contract. We have to keep the number of variants under control at this level of abstraction. Otherwise, the transformations and contract lowerings would have to deal with too many cases.
Would that work for your case?

Thanks,
Diego

In D154740#4495836, @kuhar wrote:

In D154740#4495452, @rsuderman wrote:

In D154740#4494857, @kuhar wrote:

Do you plan to add some tests, or is this covered by some existing one?

Happy to add some. I am less familiar with this area in the codebase so thoughts on how / where to test is appreciate.

I checked and the code from this patch is not exercised by any lit test. The helper is used with the other types in these:

Dialect/Linalg/IR/LinalgOps.cpp
Dialect/Linalg/Transforms/ElementwiseOpFusion.cpp
Dialect/Linalg/Transforms/ConvertConv2DToImg2Col.cpp
Dialect/SparseTensor/Transforms/CodegenUtils.cpp

So I'd think we either add some linalg/sparse tensor tests, or a new test pass.

Added testing and added complex type support for ConvertConv2DtoImg2Col

git-clang-format

Updated to check ComplexType directly.

In D154740#4494857, @kuhar wrote:

Do you plan to add some tests, or is this covered by some existing one?

Rebased on head

Add operand bailout

Factored into helper functions and performed general var name cleanup.

Updated for jpienaar@ comments. Included adding complex.bitcast -> arith.bitcast canonicalizer.

Rebased on main

Formatting changes and float -> double correction.

Expand f32Cst to take double

More windows compilation failures.

Fixed windows build

One change before landing. Everything is broken up between 3-4 files of <100 lines in length. It doesn't seem worth fracturing this up to this degree. Could you have TosaFolders.cpp and merge them all together, including the transpose pass)

I can land now

Add matching element type