I read the brief introduction on cranelift crates here
I did not see anything about linking. So if I were to generate cranelift IR, and then lower for each target to module or "object file". In the final stage, I would want to link all objects together, and do different (link time) optimizations. Is there a distinction in cranelift, or at that point is it using the codegen crate on a massive in memory IR of all objects?
(sorry just getting started here)
I also have no idea how this site works, or what it means to be in a stream, or what it said when this message was outside the arrow? sorry.
oh i feel dumb.
cranelift-module This crate manages compiling multiple functions and data objects together.
This is called a module in cranelift world.
Chris Clark has marked this topic as resolved.
@Chris Clark Cranelift works purely on a function level right now, i.e., each function is compiled separately with no knowledge of other functions. (The original design motivation for this was to allow easy parallel compilation, AFAIK.) As a result, there's no LTO, and no need to have everything in memory while compiling
Chris Clark has marked this topic as unresolved.
In the future we may implement inlining though, in which case it'd be beneficial to present the IR for multiple functions to the backend; we haven't quite worked out how to update our model for that
In any case, yep, you've discovered some of the machinery for this. Note that Cranelift is factored into layers of sorts: cranelift-codegen is the core backend, and is just as described above; cranelift-module, cranelift-object, and cranelift-jit are some of the higher level surface that's been built to enable linking, storing code to disk, etc
@bjorn3 is probably the best person to ask for most questions related to that; I mostly work on the core compiler and on Wasmtime (which does its own sort of relocs / linking)
I just want to add that you're using this Zulip chat just fine, and also to say, welcome!
Chris Fallin said:
Chris Clark have everything in memory while compiling
I'm not sure how this will work with the final binary, but I'll look more into module and object, to see what I can leverage. I just don't want to work with llvm I've decided. This interface already seems leagues better. thank you for all the hard work already!
Yep, and just to echo Jamey, please feel free to ask questions here! We are fairly young w.r.t. documentation and good examples (the main users now are Wasmtime and then the rustc backend cg_clif) so we're always interested in helping more small projects bootstrap and then serve as good examples in turn, and find the holes in our docs so we can improve them!
Should I provide additional follow up here, is a "stream" continuous, all linking type questions go here? Should my poc research results be a separate stream?
A topic within a stream can continue being used for arbitrarily long, yes. I think the idea is that it gives someone the ability to focus on one line of conversation if there are multiple going on at the same time (e.g. the classic "three simultaneous convos interwoven in an IRC channel")
it's also somewhat useful to see the title when quickly triaging incoming messages, so if a topic drifts too far we sometimes start a new one. but there's really nothing wrong with a generic one like "linking" or "beginner questions" or "strange crash" or ...
at least, that's how I use Zulip, dunno if others have different thoughts :-)
Zulip allows moving messages to a new topic after the fact if it drifted too far from the original conversation.
Last updated: Nov 22 2024 at 16:03 UTC