Integer polyfills

We should have polyfills to downlevel u64 and u128 to many u32 instructions, enabling the use of these types without concern for hardware capabilities on eg. mobile ARM platforms. Also consider polyfill for u8 and u16, which could enable things like using enum Ordering from std, see https://github.com/Rust-GPU/rust-gpu/issues/147.

libm only handles float math, no integer downlevel.

Discussed in https://github.com/Rust-GPU/rust-gpu/discussions/301

^{Originally posted by nazar-pc June 27, 2025}
I faced a small challenge: my CPU code I'm trying to run on a GPU naturally maps onto u64 and u128, but even u64 apparently requires OpCapability Int64, let alone u128.

Now writing polyfills that work around that feels like a job that compiler should do for me, though I appreciate that it at least tells me that there isn't a native way to run that and I should think about what to do with it.

I'm wondering it it'd be possible to either have a compilation flag that automatically inserts polyfills for such types. It will be an explicit opt-in feature, but otherwise require the least amount of effort for those who do need it. I believe LLVM is capable of this.

I'm really not looking forward to writing polyfills for u128 using a bunch of u32s.

Beginnen Sie mit der Problembeschreibung und der verlinkten Diskussion 301 und prüfen Sie anschließend das verwandte Issue 147 hinsichtlich der vorgeschlagenen Anwendungsfälle und Einschränkungen für Integer. Legen Sie fest, welche Integerbreiten und Zielinstruktionen in den Umfang fallen, wie Opt-in-Polyfilling funktionieren soll und welche Tests die Unterstützung vor Beginn der Implementierung nachweisen würden.