Improvements to JITLink, to ease transition #54841
Conversation
|
PPC got further than I expected. Seems like we should try backporting: |
|
Both are on LLVM 18 so I wonder if we should skip a release with 17, since the big changes that cause issues for people are already there (no opaque ptrs) |
I don't think we're committed to have each major LLVM version in a Julia minor version: Julia v1.5 had LLVM 9, v1.6 had LLVM 11. |
vtjnash
force-pushed
the
jn/jitlink-always
branch
from
67b2e36
to
42dfce2
Compare
vtjnash
force-pushed
the
jn/jitlink-always
branch
from
42dfce2
to
17634d9
Compare
vtjnash
changed the title
| if (!decls.specFunctionObject.empty()) | ||
| NewDefs.push_back(decls.specFunctionObject); | ||
| } | ||
| auto Addrs = jl_ExecutionEngine->findSymbols(NewDefs); |
There was a problem hiding this comment.
This is the thing we discussed that makes the memory a little better right?
There was a problem hiding this comment.
Yes, this helps because it ensures it does the whole graph at once (behind the codegen lock). We can also later turn off the logic that tries to filter the graph, but this already should give the performance effect
vtjnash
force-pushed
the
jn/jitlink-always
branch
from
17634d9
to
8419f12
Compare
Seeing what this will look like, since it has a number of features (delayed compilation, concurrent compilation) that are starting to become important, so it would be nice to switch to only supporting one common implementation of memory management. Refs #50248 I am expecting llvm/llvm-project#63236 may cause some problems, since we reconfigured some CI machines to minimize that issue, but it is still likely relevant.
vtjnash
force-pushed
the
jn/jitlink-always
branch
from
8419f12
to
218edea
Compare
Seeing what this will look like, since it has a number of features (delayed compilation, concurrent compilation) that are starting to become important, so it would be nice to switch to only supporting one common implmenetation of memory management.
Refs #50248
I am expecting llvm/llvm-project#63236 may cause problems, since we reconfigured some CI machines to hide that issue, but it is still likely relevant.