[WIP] dialects: (arith) Fix arith.constant to return only signless integers

[compor]

This PR:

• Fixes arith.constant to return only signless integers
• Adds tests of the above

Resolves #1101

cc @n-io @dk949
A side effect of this is that some of CSL backend tests are broken, as they use arith.constant to generate signed and unsigned integers for various bit widths.

I've fixed print_csl.mlir by adding csl.mlir.signedness_casts which creates benign(?) artifacts of @as(i32, 100) vs plain 100. I'm hoping these are essentially optimized away by the CSL compiler/SDK, but I couldn't find anything related by a cursory look in the docs.

More involved fixes would be need in the CSL canonicalization patterns, as they explicitly check for the existence of arith.constant ops.

@superlopuh my suggestion would be for the CSL ppl to create a separate PR to fix these before this going in, not sure if you agree.

Failing filecheck tests:

dialects/csl/csl-canonicalize.mlir
transforms/csl-stencil-handle-async-flow.mlir
transforms/memref-to-dsd.mlir

[superlopuh]

I'm a bit confused by the "fix", why is this desirable?

[compor]

I'm a bit confused by the "fix", why is this desirable?

What fix are you referring to? The arith or the CSL part?

If it is for arith, then arith.constant 0 : si32 is not valid IR.

[superlopuh]

The second, I can't find this constraint in the description here: https://mlir.llvm.org/docs/Dialects/ArithOps/#arithconstant-arithconstantop

I tried it on godbolt and you're right: https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1AtaeMkvrICeAZUboAwqloBXFgz32AMngaYAcm4ARpjEIABMpAAOqAqENgxOru56MXHWAj5%2BgSwhYZEWmFYJQgRMxARJbh5cpIXFAqXlBFkBwaERdWUVVSm1Ct0tvm25HeEAlHWoLsTI7BzlhAgAdGgMA4YEANQaWyBbcQDM4QCkGgCCHJO0nACsvB4cWqSonACyXgCSAEoH07OYLYncKHHikAiaK6TADWIEOh2W8KRyJRADZ9JxJA9IS9OLwFCANODIZM4LAkGgWFE6KFyJRKdT6GETGZUFECFxURoiTRaARQgSIEEcUFfOUAJ6cMGi5jEcUAeSC2iKEO4vEpbEE8oYtElT14WCCLmADjEtAJatIWBYhmA4n1VrMKrwADdMBbnphVEUXPypbxfPybg7TEFiBKnFgcQRiHgWP7SG7iEFYpgACKYG1GUxGEl8AzABQANTwmAA7vKoowE/xBCIxOwpDJBIoVOoHbpagZcyyyKGCZBJmyMus8S8k7GsAOIJN6iO7AxHM5qiBbrVvMMcnkQNI0vEBL0PGvorF9wxWluOtI5yVBofV/1MJYR00Khf2mFr3flyljxs35uH47rO/xzBI1x3NiDqvBwWwfD8WzDlsnLLBoqFbBAuCECQQIglw4y8KqWjjDCcIIiiFFIuiwZYqQjzPDB%2BKEsS%2BqkjAiAgNMBBRL6dIQAyNLEP4rDzPBvxIShaGevgRCTnotbCKI4hNgprZqDinakGW4ZRP6EEcPcdE4jB8q%2Bjx2yoFQcFfOJ7LIaiqHoRAThUoJuGggRLHEaR8KIpRFEYhwtH0bwjF1MxRFQoF4RQQxY6RSRiYCgkO5AA

[compor]

Yeah, that's right, I think the docs should say "signless integer-like" etc. I believe that's why it slipped.

But thinking about it, arith is a high enough level of abstraction to deal with signless only integers, so it makes sense within the MLIR rationale, just poor documentation.

The second, I can't find this constraint in the description here: https://mlir.llvm.org/docs/Dialects/ArithOps/#arithconstant-arithconstantop

I tried it on godbolt and you're right: https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1AtaeMkvrICeAZUboAwqloBXFgz32AMngaYAcm4ARpjEIABMpAAOqAqENgxOru56MXHWAj5%2BgSwhYZEWmFYJQgRMxARJbh5cpIXFAqXlBFkBwaERdWUVVSm1Ct0tvm25HeEAlHWoLsTI7BzlhAgAdGgMA4YEANQaWyBbcQDM4QCkGgCCHJO0nACsvB4cWqSonACyXgCSAEoH07OYLYncKHHikAiaK6TADWIEOh2W8KRyJRADZ9JxJA9IS9OLwFCANODIZM4LAkGgWFE6KFyJRKdT6GETGZUFECFxURoiTRaARQgSIEEcUFfOUAJ6cMGi5jEcUAeSC2iKEO4vEpbEE8oYtElT14WCCLmADjEtAJatIWBYhmA4n1VrMKrwADdMBbnphVEUXPypbxfPybg7TEFiBKnFgcQRiHgWP7SG7iEFYpgACKYG1GUxGEl8AzABQANTwmAA7vKoowE/xBCIxOwpDJBIoVOoHbpagZcyyyKGCZBJmyMus8S8k7GsAOIJN6iO7AxHM5qiBbrVvMMcnkQNI0vEBL0PGvorF9wxWluOtI5yVBofV/1MJYR00Khf2mFr3flyljxs35uH47rO/xzBI1x3NiDqvBwWwfD8WzDlsnLLBoqFbBAuCECQQIglw4y8KqWjjDCcIIiiFFIuiwZYqQjzPDB%2BKEsS%2BqkjAiAgNMBBRL6dIQAyNLEP4rDzPBvxIShaGevgRCTnotbCKI4hNgprZqDinakGW4ZRP6EEcPcdE4jB8q%2Bjx2yoFQcFfOJ7LIaiqHoRAThUoJuGggRLHEaR8KIpRFEYhwtH0bwjF1MxRFQoF4RQQxY6RSRiYCgkO5AA

[compor]

@n-io @dk949 any thoughts on this wrt the CSL changes?