[FXML-4614] Add EmitC index types, lower arith.index_cast, arith.index_castui

[cferry-AMD]

This PR:

• introduces new emitc.size_t and emitc.ssize_t data types, and a type converter (index goes to emitc.size_t),
• makes the ArithToEmitC pass use the type converter,
• adds EmitC lowering for arith.index_cast, arith.index_castui.

[cferry-AMD]

Leaving this here for today, with the linker failing -- it works on my end with a clean build, so what happens here in the CI is really strange.

[mgehre-amd]

Leaving this here for today, with the linker failing -- it works on my end with a clean build, so what happens here in the CI is really strange.

Try adding the MLIREmitCTransforms library into the list of dependencies of MLIRArithToEmitC

[mgehre-amd]

Looks good!

[mgehre-amd]

Can you please check that the behavior of casting between index and i1/bool is correct? Bool behaves pretty special (not truncating but checks v != 0).

[josel-amd]

LGTM. Discussed offline a small possible (although unlikely) issue with ssize_t.

[cferry-AMD]

Can you please check that the behavior of casting between index and i1/bool is correct? Bool behaves pretty special (not truncating but checks v != 0).

Good remark. We don't handle that and the same remark was formulated for float-to-int casts where this was made illegal. Per the semantics of index_cast you'll expect a truncation i.e. keep only the parity bit which is clearly defined, so I'd preserve this behavior and do something like (bool)(v & 0x01). How does that sound?

[mgehre-amd]

Can you please check that the behavior of casting between index and i1/bool is correct? Bool behaves pretty special (not truncating but checks v != 0).

Good remark. We don't handle that and the same remark was formulated for float-to-int casts where this was made illegal. Per the semantics of index_cast you'll expect a truncation i.e. keep only the parity bit which is clearly defined, so I'd preserve this behavior and do something like (bool)(v & 0x01). How does that sound?

Sounds good!

[cferry-AMD]

To be more specific @josel-amd : the discussion was on the fact that ssize_t must only represent all size_t values and -1, excluding anything below -1. However, like we discussed above for truncation when going to size_t, in practice this will rarely if ever cause a problem since most compilers use the largest signed ints they can to implement ssize_t. So we'll just leave this as it is.