Optimize emitted opaque closures #57
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Perform IR interpretation and run an inlining pass on the opaque closures that we emit, resulting in faster generated code (~2x for
onecall!
/twocall
for example) at the cost of increased compilation time.From what I understand, for DAECompiler the performance trade-off leans heavily toward cutting down compile times, so I'm not sure that this change is desired. Nevertheless, that's something I might need to do for Mooncake to keep decent performance, and I thought this might be worth making a PR here to at least discuss it. I haven't profiled the increase in compile times, it might not be that much of an increase overall given that most extra inference should be concrete.
Requires JuliaLang/julia#59671.
The optimization pass seems to introduce correctness issues at the moment in some cases, which are caught by failing tests. That will require further troubleshooting.