-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
simplify interaction between new JITs and codegen #15556
Conversation
0b7171e
to
32c093a
Compare
delete specf; | ||
specf = temp; | ||
} | ||
if (specf) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (f)
?
I'm generally fine with this, even though it goes in the opposite direction from where I was taking it. I do worry about the performance implications of creating this many modules, but since we're at least not doing per-module codegen, it might not be that bad. As I mentioned, I would like to see some of this code move into ORCJIT proper eventually, but I'm fine with leaving it like this if it makes compatibility with the old JITs easier. |
2a65a90
to
dcc3035
Compare
bump. this is ready to merge. |
dcc3035
to
82af1e7
Compare
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT, but using Module as the atomic unit instead of Function this gets codegen closer to being separable (cachable) at the module level, with the remerging happening in the JIT after object file emission fix #15533
82af1e7
to
a727e16
Compare
// this assumes that the targets of the two modules are the same | ||
// including the DataLayout and ModuleFlags (for example) | ||
// and that there is no module-level assembly | ||
static void jl_merge_module(Module *dest, std::unique_ptr<Module> src) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
breadcumb: in the future, we may want to just call Linker::linkModules
(introduced in llvm-3.8 for LTO), but for now, our actual usage is much easier than that because we don't need full generality (or barely any at all), so we can just do the simple thing here
I think this broke the
|
this treats the new JITs (MCJIT, ORCJIT) much like the old JIT, but using Module as the atomic unit instead of Function
reviewer note: much of the code motion is moving the logic to interact with the JIT into jitlayers.cpp. this is not yet separable from codegen.cpp, but I expect they should be able to divide into separate compilation units in the future.
TODO:
fix #15533