set alignment of i128 to 16

[Firestar99]

As we need to change the target specs, and target specs are dependent on rustc version to provide backwards compatability with older rustc_codegen_spirv versions, we can only really change target specs when we update rustc. So we've got the choice of:

• delay this PR and merge it with rustc 1.100 #664, but @nazar-pc will likely stay on rustc 1.99 for a while
• act as if this changed with the rustc 1.99 update in PR 630. This introduces a minor cargo-gpu backwards compatability breakage with commits between the rustc 1.99 update and this PR. But I feel like that's a fine tradeoff.

See https://llvm.org/docs/LangRef.html#data-layout for how to specify data layouts.

close #665

[nazar-pc]

to provide backwards compatability with older rustc_codegen_spirv versions

Can someone educate me what is the benefit of this? Sorry if this is the wrong place to ask,but I've seen this backwards compatibility surfacing a few times and I'm not sure why it is important if the toolchain is fixed and is generally kept in sync with the rest of rust-gpu stack.

[Firestar99]

TLDR: So your locally installed cargo-gpu can compile older rust-gpu projects.

There's the dependency chain of cargo-gpu -> cargo-gpu-install -> spirv-builder with the latter calling cargo +nightly-???? build --target spirv-unknown-????. spirv-builder maintains backwards compat so you can have a newer cargo gpu version installed and still compile older rust-gpu projects using it. Reinstalling cargo gpu just to compile an older project sucks.
Now this doesn't really affect cargo-gpu-install as you'll likely keep it in sync with your spirv-std anyway.
But as long as maintaining backwards compat is as cheap as our target spec generator being versioned by rustc version, I'm willing to keep it.

[nazar-pc]

I see, so this is just for CLI. I'm now wondering if it would be possible to move this target logic elsewhere, so CLI is a thin wrapper instead. For example, by compiling not just SPIR-V backend shared library, but also some kind of "real" binary that cargo-gpu can then delegate to, and the delegated version will always match the intended version exactly.

Not that it matters to me personally, but I think that might survive backward and forward compatibility a bit better.

[Firestar99]

We've had that if you go waaay back towards the first cargo-gpu versions schell made... and it was very annoying to maintain. Imagine it as a copy of the current spirv-builder you'd configure and serialize to send that json to another spirv-builder compiled by rust-gpu's rustc version that deserializes it and passes it onto the real spirv-builder. Now we just have one spirv-builder.

[nazar-pc]

I'd just expect a thin wrapper that builds "real" cargo-gpu from correct checkout and delegates to it with all CLI options as is. Shouldn't be too bad, but I do not have experience with what it was like before.