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.

Start with the issue description and the linked discussion 301, then review the related issue 147 for the proposed integer use cases and constraints. Define which integer widths and target instructions are in scope, how opt-in polyfilling should work, and what tests would demonstrate support before implementation begins.