Large integer polyfills (libcore)

[nazar-pc]

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.

[Firestar99]

Int64 (and Int16, Int8, FP64 and to a degree F16) are available on effectively all desktop machines (including iGPUs), so when exclusively targeting them, you should be fine requiring Int64. Vulkan drivers for Android are known to be pretty bad at times, there I wouldn't assume anything. And even if you had Int64 emulation, these platforms would likely be too slow anyway for that to matter.

We have not had anyone ask for i128 support, that's a rather rare use-case.

About polyfills, I don't think they'd be too hard to add. I added some in #213 for leading_zeros(), trailing_zeros() and count_ones() since SPIR-V only supports these ops to be i32, so some polyfill was necessary for i8, i16 and i64. But it really depends on what kind of ops you'd like to have, add sub and mul should be easy but the rest will be tricky.

Have you tried out if calling libm just works for i128 emulation? Note that we're stuck at libm 0.2.11 due to #244

[nazar-pc]

I do want to target various iGPUs indeed. The lowest one I'm potentially considering is Raspberry PI 5 and feature set there isn't spectacular:

VkPhysicalDeviceFeatures:
=========================
	robustBufferAccess                      = true
	fullDrawIndexUint32                     = true
	imageCubeArray                          = true
	independentBlend                        = true
	geometryShader                          = true
	tessellationShader                      = false
	sampleRateShading                       = true
	dualSrcBlend                            = false
	logicOp                                 = true
	multiDrawIndirect                       = false
	drawIndirectFirstInstance               = true
	depthClamp                              = true
	depthBiasClamp                          = true
	fillModeNonSolid                        = true
	depthBounds                             = true
	wideLines                               = true
	largePoints                             = true
	alphaToOne                              = true
	multiViewport                           = false
	samplerAnisotropy                       = true
	textureCompressionETC2                  = true
	textureCompressionASTC_LDR              = true
	textureCompressionBC                    = false
	occlusionQueryPrecise                   = true
	pipelineStatisticsQuery                 = false
	vertexPipelineStoresAndAtomics          = true
	fragmentStoresAndAtomics                = true
	shaderTessellationAndGeometryPointSize  = true
	shaderImageGatherExtended               = true
	shaderStorageImageExtendedFormats       = true
	shaderStorageImageMultisample           = false
	shaderStorageImageReadWithoutFormat     = true
	shaderStorageImageWriteWithoutFormat    = false
	shaderUniformBufferArrayDynamicIndexing = false
	shaderSampledImageArrayDynamicIndexing  = false
	shaderStorageBufferArrayDynamicIndexing = false
	shaderStorageImageArrayDynamicIndexing  = false
	shaderClipDistance                      = true
	shaderCullDistance                      = false
	shaderFloat64                           = false
	shaderInt64                             = false
	shaderInt16                             = false
	shaderResourceResidency                 = false
	shaderResourceMinLod                    = false
	sparseBinding                           = false
	sparseResidencyBuffer                   = false
	sparseResidencyImage2D                  = false
	sparseResidencyImage3D                  = false
	sparseResidency2Samples                 = false
	sparseResidency4Samples                 = false
	sparseResidency8Samples                 = false
	sparseResidency16Samples                = false
	sparseResidencyAliased                  = false
	variableMultisampleRate                 = false
	inheritedQueries                        = true

We have not had anyone ask for `i128 support, that's a rather rare use-case.

I have some operations that work on a bunch of bits that is less than 128, so using u128 as a container for storing them is actually very convenient when I need to extract certain number of bits at certain offset. Same use for u64 actually, mostly a container of bits bit manipulations (shifts and logical &|^) and casting to/from u32.

So u128 makes the most sense there and even if the support is emulated, I don't think it would save more than a handful of instructions overall when meticulously writing everything with u32s explicitly rather than going through generic polyfill.

I expect standard library integer types to "just work". LLVM is typically responsible for these polyfills from my understanding, but here the job would be on spirv backend.

For now I did write minimal polyfill for u64 using u32s just for operations that I need and similarly for u128 using both u32s and u64s, depending on what is available (this is where #304 came from when I was writing feature detection), but I'd prefer to not have it long-term.

Have you tried out if calling libm just works for i128 emulation? Note that we're stuck at libm 0.2.11 due to #244

That is for various math functions, but I only need basic bit manipulation and integer casting only.