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!
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!
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!
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.
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.
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!
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 ofcranelift_codegen
?Or would it be out of scope since it requires a bit more logic than just being a builder pattern wrapper
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
orcranelift_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, butcg_clif
has its own ABI details that it imports fromrustc
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: Dec 23 2024 at 12:05 UTC