Preparing for C ABI changes

[tlively]

I saw in #309 (comment) that the witx tooling the WASI ecosystem uses depends on the details of the WebAssembly C ABI. There are a couple changes we are discussing making in a new C ABI, so I wanted to check in and see if any of them present a compatibility risk with the WASI ecosystem. If so, we should discuss whether the changes are worth the cost and how to make any ABI transition as seamless as possible.

First, there is discussion about changing the alignment of long double from 16 bytes to 8 bytes. This could change the memory layout of any struct containing long doubles. Does the WASI ecosystem use long double at all?

Second, we are considering introducing a new calling convention when multivalue is enabled in LLVM. If we do enable that new calling convention by default whenever -mmultivalue is passed to clang (or multivalue is enabled in rustc), what kind of changes would be needed in the witx tooling?

[sunfishcode]

No WASI APIs themselves use long double, so the question would be whether there are any users using long double. I don't think we have a reliable way to determine this.

Concerning -mmultivalue, no immediate changes to witx tooling are needed to keep things working, as the witx tooling currently lowers multiple return values into out paramters itself before clang sees anything, so it will work the same way with or without -mmultivalue. So from WASI's perspective, you can go ahead with this transition, and then we'll update the witx tooling to translate witx multivalue into wasm multievalue once the transition has settled.

[tlively]

Thanks, @sunfishcode! That's all I needed to know, so I'll go ahead and close the issue :)