[mlir][dxsa] Add dtof, ftod, dtoi, dtou, itod and utod instructions

[tagolog]

Example:
dxsa.dtof r<0, <x, y>>, r<1>
dxsa.ftod r<0>, r<1>
dxsa.dtoi r<0, <x, y>>, r<1>
dxsa.dtou r<0, <x, y>>, r<1>
dxsa.itod r<0>, r<1>
dxsa.utod r<0>, r<1>

[hvdijk]

We really should have some sort of order for the instructions in this file. I have, for lack of a better option, just kept the bitwise instructions I've added in alphabetical order; it's going to cause merge conflicts to have other unrelated instructions inserted in the middle of them when I add more. Do you have any particular preference on this?

[tagolog]

Good point. I've reworked this: the conversion opcodes now live together in a dedicated "Type conversion instructions" block in the main switch, kept in alphabetical order (dtof, dtoi, dtou, f16tof32, f32tof16, ftod, ftoi, ftou, itod, itof, utod, utof), so they no longer get inserted into the middle of your bitwise block.

[hvdijk]

What's the reason for putting the double conversions in their own file rather than in DXSATypeConversionOps.td?

[hvdijk]

I see that this is copied from the Microsoft documentation, but it doesn't make sense? 4294967295.999 isn't representable in double precision floating point, but clamping to [0.0, x] for any 4294967295.0 <= x < 4294967296.0 produces identical results, so it won't actually clamp to 4294967295.999 but also it doesn't make any difference what it actually clamps to, the decimals are just arbitrary. Do we want to just copy the documentation, or do we want to clear it up?

[tagolog]

Good point. I've dropped the clamp/NaN wording from both dtoi and dtou so they now just state "rounding toward zero", matching the existing ftoi/ftou descriptions which omit it too.

[hvdijk]

I think even though the wording didn't quite make sense, it was intended to express an important thing: it's well-defined to convert a double that is not in the range of unsigned using dtou, and likewise for the other ops. With LLVM's fptoui, this would be explicitly undefined, so highlighting that dtou is different seems worthwhile. But I'm not sure how to best express that. It's fine to say, IMO, that based on ftou's description also missing this we leave this as an issue to be resolved later; if so, shall I open an issue to make sure it's tracked (even if we never get to it)?

[tagolog]

I've created an issue to address this later #204

[tagolog]

What's the reason for putting the double conversions in their own file rather than in DXSATypeConversionOps.td?

I've merged them into DXSATypeConversionOps.td alongside the other conversions and dropped the separate DXSADoubleTypeConversionOps.td file.

[hvdijk]

Looks good to me, thanks. The same comment on the line order in the tests applies as in the other PR, and I left another comment on the description, but for both of those, we can decide not to make changes there and merge this as is IMO.