Fix slow compilation of large zero-initialized arrays; warn on large non-zero fills

[39ali]

let arr = [0; 32 * 1024] compiled very slowly. The cause: Rvalue::Repeat with a zero element routes through memset, while will create a huge list of repeated store instructions, the fix: use OpConstantNull instead when fill_byte == 0, valid for any SPIR-V composite type, single instruction regardless of size.

SPIR-V has no equivalent of OpConstantNull for non-zero values , so the best we can do is tell the user early by emitting a warning

[Firestar99]

Fix slow compilation

First, could you explain what kind of slowdown you're seeing?

use OpConstantNull instead when fill_byte == 0

I like that idea, although I'm unsure if spirt supports that command @eddyb?

will create a huge list of repeated store instructions

Isn't the bug then that the emitted OpConstantComposite was broken up into a bunch of individual OpStore instructions / not being reassembled into an OpCompositeConstruct / OpConstantComposite? (Our destructure_composites post-link pass may be related to this?)

[39ali]

i needed to clarify that for let arr = [0; 32 * 1024] it'll translate to OpConstantComposite
but for arr = [1; 32 * 1024] it'll translate to OpInBoundsAccessChain + OpStore

First, could you explain what kind of slowdown you're seeing?

compile time is slow, i believe its because of the long OpConstantComposite instruction

i'll attach the .spv file for this shader :

#![no_std]
use spirv_std::glam::Vec4;
use spirv_std::spirv;

#[inline(never)]
#[spirv(compute(threads(1)))]
pub fn self_assignment(
    #[spirv(storage_buffer, descriptor_set = 0, binding = 1)] y: &mut [f32],
) {
    let arr = [0f32; 32 * 1024];
    for i in 0..arr.len() {
        y[i] = arr[i];
    }
} 

spirv.txt