Stream: git-wasmtime

Topic: wasmtime / issue #1068 Cranelift: support aggregate types...

Wasmtime GitHub notifications bot (May 04 2022 at 20:43):

cfallin edited issue #1068:

Hello there, I have a slightly trivial question.

How does one represent a structure in Cranelift IR? I know that structures are more-or-less a virtual concept and can be introduced "virtually", by representing parts of them as different objects in memory. However, what if one wants to inter-operate with C library APIs that require passing a structure? As far as I understand, some strict memory layout standard should be followed with correct paddings and organisation.

Is there any easy way of doing this? Thanks!

Wasmtime GitHub notifications bot (May 04 2022 at 20:43):

cfallin labeled issue #1068:

Hello there, I have a slightly trivial question.

How does one represent a structure in Cranelift IR? I know that structures are more-or-less a virtual concept and can be introduced "virtually", by representing parts of them as different objects in memory. However, what if one wants to inter-operate with C library APIs that require passing a structure? As far as I understand, some strict memory layout standard should be followed with correct paddings and organisation.

Is there any easy way of doing this? Thanks!

Wasmtime GitHub notifications bot (May 04 2022 at 20:43):

cfallin labeled issue #1068:

Hello there, I have a slightly trivial question.

How does one represent a structure in Cranelift IR? I know that structures are more-or-less a virtual concept and can be introduced "virtually", by representing parts of them as different objects in memory. However, what if one wants to inter-operate with C library APIs that require passing a structure? As far as I understand, some strict memory layout standard should be followed with correct paddings and organisation.

Is there any easy way of doing this? Thanks!

Wasmtime GitHub notifications bot (Mar 07 2023 at 11:30):

bjorn3 commented on issue #1068:

Should we close this as out of scope? We already removed the heap concept used to represent the webassembly linear memory. It should be possible to write an external crate for convenient handling of higher level types which desugars struct accesses into primitive accesses.

Wasmtime GitHub notifications bot (Mar 07 2023 at 18:18):

cfallin commented on issue #1068:

Yeah, I think that in the three years (!) since the above discussion, we've come to a clearer consensus about the level of abstraction in CLIF. Namely, we have a view of the world that consists of primitive integer/float types, and loads/stores; and higher-level abstractions can be built from those by the producer. This is explicitly lower-level than LLVM, where one does have a notion of aggregate types and the compiler is responsible for computing their layout. Having only register-sized values makes many things simpler here.

So I'll go ahead and close this as @bjorn3 suggests but anyone please do feel free to leave a note here if there is a compelling argument for this that we've missed.

Wasmtime GitHub notifications bot (Mar 07 2023 at 18:18):

cfallin closed issue #1068:

Hello there, I have a slightly trivial question.

How does one represent a structure in Cranelift IR? I know that structures are more-or-less a virtual concept and can be introduced "virtually", by representing parts of them as different objects in memory. However, what if one wants to inter-operate with C library APIs that require passing a structure? As far as I understand, some strict memory layout standard should be followed with correct paddings and organisation.

Is there any easy way of doing this? Thanks!

Wasmtime GitHub notifications bot (Jul 06 2023 at 18:47):

simvux commented on issue #1068:

Would it not make sense to support aggregate types in the cranelift_frontend crate as it aims to provide an optional convenience on top of cranelift_codegen?

Or would it be out of scope since it requires a bit more logic than just being a builder pattern wrapper

Wasmtime GitHub notifications bot (Jul 06 2023 at 19:14):

cfallin commented on issue #1068:

In principle it could be, but I think over time we've converged on cranelift_frontend being mostly a wrapper around SSA construction -- it doesn't really have much else in the way of "semantic lowering".

It's possible we could add another abstraction layer -- cranelift_values or cranelift_struct_abi or something -- that has its own type system that is a superset of core CLIF's, and can handle aggregate types and match the native C ABI for passing them as args and returns. Perhaps part of the reason this doesn't exist yet is that as one moves up the abstraction layers, details start to become application-specific -- for example, a C compiler using Cranelift may want exactly what was just described, but cg_clif has its own ABI details that it imports from rustc and associated support code and data model.

If you're interested in designing and building such a thing, I think we'd be open to at least helping with the design. It might make sense to build it out-of-tree first, and if it becomes useful for a large number of users then it could eventually move in-tree.

Last updated: Nov 22 2024 at 16:03 UTC