Emulate non-native instrs (e.g. uint128)

[jon-chuang]

One can possibly fully/partially emulate uint128 functionality by representing as two uint64s or whichever other capabilities are available. One can implement this generically so that any uint e.g. uint64 can be emulated with lower capabilities, e.g. uint32.

While this emulation can be done on the user side, it seems cleaner to expose emulated capabilities.

[jon-chuang]

One could possibly infer this at the instr emission stage from the operand ty. So at this point I’m not sure if the ty is rust types or SpirvType. I think it’s the latter.

[khyperia]

Just to get some background to help us place this on the roadmap, what are the use cases you have in mind for u128? Have you seen emulated u128s elsewhere before (e.g. GLSL)?

[jon-chuang]

Well the specific use-case I have is a 64 X 64 -> 128-bit wide mul and also add with carry used in cryptography.

These are straightforward to emulate.

I was thinking that it's not clear how much utility this would bring, esp. since for the full proposal one must keep track of what capabilities are available at the emission stage. So one might have to define different spirvtypes like u128_on_u64 and u64_on_u32 etc. Or maybe a generic type with type parameters

[khyperia]

Yeah, we already keep track of what capabilities are available, so that part shouldn't be too difficult. It's just a hacked-together thing at this point, though, #42 tracks making it actually be useful. We probably want to wait until that system is more thought-out before tackling this.

[Jasper-Bekkers]

An additional note small note for feature orthogonality; it's unclear to me at this point how atomics would work on u128 and related types because of some of the remarks here: https://www.khronos.org/blog/comparing-the-vulkan-spir-v-memory-model-to-cs#_limited_forward_progress_guarantees (not saying it's impossible, just unclear to me).

[khyperia]

Yes, atomics would be disabled if using this feature set, I don't see any issues there. (Assuming there's no workaround, but, I'd say it's a pretty reasonable assumption)

[eddyb]

IIRC rustc used to have emulation for 128-bit integers on at least some targets, due to LLVM issues (sadly I don't remember more details). If someone wants to find that and retrofit it onto rustc_codegen_spirv, that might be an easy way to get support.

[DJMcNab]

It might be worth trying the extrprim crate - the implementation for extprim::u128::u128 at first glance doesn't look like it uses anything we wouldn't support, and it is normally no_std

[XAMPPRocky]

We discussed at the meeting today, and the consensus was that emulating wider integers such u128 isn't a priority for us, however we would accept a contribution from the community for it. Provided, that the code contributed is relatively straightforward and maintainable.

[khyperia]

I don't think this is on the roadmap for us, and I'm not sure we would accept a community solution due to the maintenance burden, so closing this for now.

[LegNeato]

rust-lang/rust#116909