search for: simpleinline

...x0001113619e8 by thread T13: #0 __tsan_atomic32_compare_exchange_val <null>:568340296 (libclang_rt.tsan_osx_dynamic.dylib+0x00000003e7aa) #1 llvm::sys::CompareAndSwap(unsigned int volatile*, unsigned int, unsigned int) Atomic.cpp:52 (libLTO.dylib+0x000000511914) #2 llvm::initializeSimpleInlinerPass(llvm::PassRegistry&) InlineSimple.cpp:82 (libLTO.dylib+0x000000ab2b55) #3 (anonymous namespace)::SimpleInliner::SimpleInliner() InlineSimple.cpp:50 (libLTO.dylib+0x000000ab2e8e) #4 (anonymous namespace)::SimpleInliner::SimpleInliner() InlineSimple.cpp:49 (libLTO.dylib+0x000000ab2d1...

Hello, I'm trying to improve SimpleInliner to use information given by __builtin_expect instruction (It would be better to not to inline if a call instruction is unlikely to be executed). The problem here is that it is not possible to compute control dependency relationship between the annotated branch instruction and callsites using PostD...

I am using llvm for source-to-source inlining. So I did: % llvm-gcc file_a.c file_b.c ... file_n.c -o file % opt -inline -inline-threshold=1000 < file.bc | llc -march=c > outfile.c Can anyone tell me how llvm determines if a function should be inlined, and what roll does "inline-threshold" play ? (Does the example mean that if the function body has fewer than 1000 instructions,

...the inliner implemented in LLVM is InlineSimple.cpp in the same directory, which adds cost to functions if they have recursive calls, allocas, and other features, but at the end, you'll notice that it weighs each instruction as 5 with each basic block as 20. I've omitted many details, see SimpleInliner::getInlineCost() in llvm/lib/Transforms/IPO/InlineSimple.cpp for complete calculation. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

Hi all, I was looking around in the lib/Transforms/Utils dir and ran into the BasicInliner class. Seeing a large similarity between it and the SimpleInliner Pass, I grep'd around for BasicInliner, but it doesn't seem to be used. The difference between them seems that SimpleInliner is a pass that looks at all functions, while BasicInliner is not a pass and looks only at explicitely given functions. They do however both declare an inline-thresh...

...state there are two strategies available in LLVM for function inlining: 1) Inline Always (by default only used at -O0 and -O1); 2) Inline Simple (OptLevel >= 2). The Inline Always strategy can be used in place of the Inline Simple if specifically requested by the user. The constructor of SimpleInliner (see "lib/Transform/IPO/InlineSimple.cpp") requires that we pass a Threshold value as an argument to the constructor. In general, the threshold would be set by the front-end (it could be either clang or bugpoint or opt etc.) according to both the OptLevel and the SizeLevel. In order...

Hi, the attached patch splits the loop unroll pass into a LoopUnroll superclass that implements the unrolling mechanism, and a SimpleLoopUnroll subclass implementing the current policy. This split is modeled after the split between Inliner and SimpleInliner. The superclass currently still finds out the TripCount and TripMultiple, and passes those, together with the Loop in question, to a policy method. Currently, TripMultiple is not yet used in the SimpleLoopUnroll, but I can imagine that this might change, so I included it already. Currently, ther...

...+ Builder->populatePostIPOPM(*LPM); } Index: lib/Transforms/IPO/InlineSimple.cpp =================================================================== --- lib/Transforms/IPO/InlineSimple.cpp (revision 187135) +++ lib/Transforms/IPO/InlineSimple.cpp (working copy) @@ -72,6 +72,10 @@ return new SimpleInliner(Threshold); } +Pass *llvm::createTinyFuncInliningPass() { + return new SimpleInliner(40); +} + bool SimpleInliner::runOnSCC(CallGraphSCC &SCC) { ICA = &getAnalysis<InlineCostAnalysis>(); return Inliner::runOnSCC(SCC); -------------- next part -------------- Index: include/...

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

On Sep 17, 2013, at 10:10 AM, Andrew Trick <atrick at apple.com> wrote: > LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to

On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote: > Wait, I have a terrible idea. Why don't we roll our own .init_array style > appending section? I think we can make this work for all toolchains we > support. > Andy and I talked about this, but I don't think its worth it. My opinion is: 1. For tool options (the top-level llc, opt, llvm-as

...iciently general form you could probably do this with an intrinsic (assuming you definitely knew you wanted to inline it). Generally I think it's outside the design space that MCJIT intends to target. Yes, I also think so, it's a problem of code generation. I will try to adapt the current SimpleInline pass of llvm and use the internal state of VMKit/J3 to retrieve the IR of an already generated function. As I have to keep a map that associates names to llvm::Function in VMKit, I just have to use it to find the code. > > So, to summarize, I think that the current implementation of MCJIT is...

...iciently general form you could probably do this with an intrinsic (assuming you definitely knew you wanted to inline it). Generally I think it's outside the design space that MCJIT intends to target. Yes, I also think so, it's a problem of code generation. I will try to adapt the current SimpleInline pass of llvm and use the internal state of VMKit/J3 to retrieve the IR of an already generated function. As I have to keep a map that associates names to llvm::Function in VMKit, I just have to use it to find the code. > > So, to summarize, I think that the current implementation of MCJIT is...

...general form you could probably do this with an intrinsic (assuming you definitely knew you wanted to inline it). Generally I think it's outside the design space that MCJIT intends to target. > > Yes, I also think so, it's a problem of code generation. I will try to adapt the current SimpleInline pass of llvm and use the internal state of VMKit/J3 to retrieve the IR of an already generated function. As I have to keep a map that associates names to llvm::Function in VMKit, I just have to use it to find the code. > >> >> So, to summarize, I think that the current implementation...

...form you could probably do this with an intrinsic (assuming you definitely knew you wanted to inline it). Generally I think it's outside the design space that MCJIT intends to target. >> >> Yes, I also think so, it's a problem of code generation. I will try to adapt the current SimpleInline pass of llvm and use the internal state of VMKit/J3 to retrieve the IR of an already generated function. As I have to keep a map that associates names to llvm::Function in VMKit, I just have to use it to find the code. >> >>> >>> So, to summarize, I think that the current im...

...form you could probably do this with an intrinsic (assuming you definitely knew you wanted to inline it). Generally I think it's outside the design space that MCJIT intends to target. >> >> Yes, I also think so, it's a problem of code generation. I will try to adapt the current SimpleInline pass of llvm and use the internal state of VMKit/J3 to retrieve the IR of an already generated function. As I have to keep a map that associates names to llvm::Function in VMKit, I just have to use it to find the code. >> >>> >>> So, to summarize, I think that the current im...

...could probably do this with an intrinsic (assuming you definitely knew you wanted to inline it). Generally I think it's outside the design space that MCJIT intends to target. >>> >>> Yes, I also think so, it's a problem of code generation. I will try to adapt the current SimpleInline pass of llvm and use the internal state of VMKit/J3 to retrieve the IR of an already generated function. As I have to keep a map that associates names to llvm::Function in VMKit, I just have to use it to find the code. >>> >>>> >>>> So, to summarize, I think that th...

...could probably do this with an intrinsic (assuming you definitely knew you wanted to inline it). Generally I think it's outside the design space that MCJIT intends to target. >>> >>> Yes, I also think so, it's a problem of code generation. I will try to adapt the current SimpleInline pass of llvm and use the internal state of VMKit/J3 to retrieve the IR of an already generated function. As I have to keep a map that associates names to llvm::Function in VMKit, I just have to use it to find the code. >>> >>>> >>>> So, to summarize, I think that th...

Hi Gaël, Thank you for the detailed explanation. It's very helpful. All of the things you describe could be done within MCJIT, but I'm not sure that's where they belong. We had a discussion about lazy function compilation at the LLVM Developers Meeting last week and the consensus among those present was that it would be better to leave this sort of lazy compilation to the MCJIT

Hi Andrew, hi all, I already saw that the old jit was (almost) deprecated. So, I'm currently playing with the new jit and it's look very interesting. (I'm working locally and I haven't pushed anything new on VMKit because I'm also changing a little the design vmkit). For the moment, MCJIT does not work with VMKit (but I haven't yet tested the safepoint/stackmap patch), I