Check isIntOrFloat before querying bitwidth

[IanWood1]

The element type must be an int or float before using getIntOrFloatBitWidth. This adds a check if the element type is an int or float, otherwise don't adjust innermost tile size. Introduced by commit c80fa3b

1/2 fix for #19167.

[MaheshRavishankar]

If you have a test that would be useful to add to https://github.com/iree-org/iree/blob/main/compiler/src/iree/compiler/Codegen/LLVMCPU/test/select_x86_64_lowering_strategy.mlir or any other select_*.mlir file there

[hanhanW]

I'm not aware that there are types other than int/float being the inputs of codegen. Can you elaborate how you discover the case and how does it get to the CPU codegen inputs? Or can you give me an example that can reproduce it at iree-opt/iree-compile level?

I left a similar comment on #19185 (review)

[MaheshRavishankar]

I'm not aware that there are types other than int/float being the inputs of codegen. Can you elaborate how you discover the case and how does it get to the CPU codegen inputs? Or can you give me an example that can reproduce it at iree-opt/iree-compile level?

I left a similar comment on #19185 (review)

We can have complex types for inputs. LLaMa has complex types.

[IanWood1]

I'm not aware that there are types other than int/float being the inputs of codegen. Can you elaborate how you discover the case and how does it get to the CPU codegen inputs? Or can you give me an example that can reproduce it at iree-opt/iree-compile level?

I left a similar comment on #19185 (review)

This was popping up with complex types in https://github.com/nod-ai/shark-ai, but there were recent changes to that repo so I don't know where the llama server integration test has been moved. I think https://gist.github.com/IanWood1/ccbcc62dca7a77d00a4ceaecb8fe38a2 will repro with iree-compile --iree-hal-target-backends=llvm-cpu

Edit: you have to checkout #19187 since the other error is hit befor this one

[hanhanW]

I think 3e40798 is a better fix, which adds the computation for complex types.

In this case, can you copy below test with CPU variants to one of select_*.test?

https://github.com/iree-org/iree/blob/main/compiler/src/iree/compiler/Codegen/SPIRV/test/config_default_misc.mlir#L3-L42

[hanhanW]

Thanks, just a couple nits!

[IanWood1]

@hanhanW I used @giacs-epic's commit instead and added a test. I just copied the test you mentioned and adjusted the tile sizes. Would you be able to check if it makes sense?

Also, @giacs-epic are you ok with hanhan's suggestion in #19185 (comment) to commit this with you as coauthor?

[lialan]

I'm not aware that there are types other than int/float being the inputs of codegen. Can you elaborate how you discover the case and how does it get to the CPU codegen inputs? Or can you give me an example that can reproduce it at iree-opt/iree-compile level?

I left a similar comment on #19185 (review)

@IanWood1 @hanhanW A few other places that computes size (mostly in emulating narrow types) do not assume the type is a ComplexType. So perhaps we can have a better API call compared to getIntOrFloatBitwidth to get the size of a type? This is a bit confusing.

I will see if EmulatingNarrowTypes needs to support complex types.

[hanhanW]

@IanWood1 @hanhanW A few other places that computes size (mostly in emulating narrow types) do not assume the type is a ComplexType. So perhaps we can have a better API call compared to getIntOrFloatBitwidth to get the size of a type? This is a bit confusing.

I will see if EmulatingNarrowTypes needs to support complex types.

We can skip complex types in the emulation for now. My guess is that it is not needed by the emulation. If we need it, then we implement it.