llvmcall: use AlwaysInliner + test inlining behavior #18409
Conversation
|
While this is pretty close to how these functions happen to work now, I'm not sure that we fully want to define them this way. But since llvmcall should get deprecated anyways, I guess I don't care particularly. That particular comment is out-of-date since #15556. |
maleadt
force-pushed
the
tb/always_inline
branch
3 times, most recently
from
e916e26
to
f0f4318
Compare
|
No particular need for this on my side either, it just lived in my branch because I need the AlwaysInliner for pulling in CUDA's libdevice, and it seems like a net reduction of code. I got rid of the support for @vtjnash What would you replace |
maleadt
force-pushed
the
tb/always_inline
branch
from
f0f4318
to
9139878
Compare
|
Rebased, tests are passing. Any final comments? |
| @@ -141,6 +142,7 @@ void addOptimizationPasses(PassManager *PM) | |||
| // list of passes from vmkit | |||
| PM->add(createCFGSimplificationPass()); // Clean up disgusting code | |||
| PM->add(createPromoteMemoryToRegisterPass());// Kill useless allocas | |||
| PM->add(createAlwaysInlinerPass()); // Respect always_inline | |||
There was a problem hiding this comment.
This seems to have broken build on LLVM 4.0 (not sure about 3.9)
There was a problem hiding this comment.
Oh you fixed it already, thanks.
llvmcallfunctions (doesn't affect non-AlwaysInline functions)Function*'s generated by julia intollvmcall, which isn't very useful but allows us tollvmcallinlining behaviorcc @Keno, you mentioned in a comment this approach can't work; is there any disadvantage of waiting until JIT (or
jl_get_llvmf_defn+ manual optim) to inline functions?