similar to: [LLVMdev] Command Line Argument 'inline-threshold'

On Mon, Jul 04, 2005 at 03:32:39PM -0500, Long Fei wrote: > 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

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,

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

On Nov 28, 2010, at 11:39 PM, Xinliang David Li wrote: > 1. Run the inliner on bar (noop, since it has no call sites) > 2. Run the per-function passes on bar. This generally shrinks it, and prevents "abstraction penalty" from making bar look too big to inline. > 3. Run the inliner on foo. Since foo calls bar, we consider inlining bar into foo and do so if profitable. > 4.

On Sun, Nov 28, 2010 at 2:37 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 23, 2010, at 5:07 PM, Xinliang David Li wrote: > > Hi, I browsed the LLVM inliner implementation, and it seems there is room > for improvement. (I have not read it too carefully, so correct me if what I > observed is wrong). > > > > First the good side of the inliner -- the

In Unladen Swallow we (intend to) compile each function as we determine it's hot. To "compile" a function means to translate it from CPython bytecode to LLVM IR, optimize the IR using a FunctionPassManager, and JIT the IR to machine code. We'd like to include inlining among our optimizations. Currently the Inliner is a CallGraphSCCPass, which can only be run by the

Another alternative could be: ORE.emitMissed(DEBUG_TYPE, ...) << ... Then the first line of emitMissed does a check if it is enabled and if not then returns a dummy stream that does nothing for operator<< (and short-circuits all the stream operations) On Sep 15, 2017 2:21 PM, "Adam Nemet via llvm-dev" <llvm-dev at lists.llvm.org> wrote: For better readability we

Sean, hopefully you’re OK with that reasoning. I went ahead and committed this in r313691. > On Sep 16, 2017, at 10:43 PM, Adam Nemet <anemet at apple.com> wrote: > > >> On Sep 16, 2017, at 4:49 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> Actually maybe something like: >> >> if (auto &E

> On Sep 16, 2017, at 4:49 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Actually maybe something like: > > if (auto &E = ORE.emitMissed(DEBUG_TYPE)) { > E.emit(...) << ...; > } Well, the point of this interface was exactly to avoid writing a conditional. If you’re willing to use a conditional you can already write this: if

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting

Hi,It seems inliner does not take into account if a call is inside a loop. I'm trying to figure out if loop-info can be made available to the inliner. When I try to add LoopInfoWrapperPass to Inliner.cpp, diff --git a/llvm/lib/Transforms/IPO/Inliner.cpp b/llvm/lib/Transforms/IPO/Inliner.cppindex 568707d..cb51ea8 100644--- a/llvm/lib/Transforms/IPO/Inliner.cpp+++

FYI - There is currently an architectural issue which prevents the SCC pass manager (which runs the inliner) from relying on Function or Loop analysis passes. This is the primary motivation of the pass manager rewrite that Chandler Carruth has been working on for the last two years. He's getting relatively close to that project being done, but until then you are going to be effectively

Larry, On Wed, Aug 11, 2010 at 4:55 PM, Larry Gritz <lg at larrygritz.com> wrote: > I have a whole slew of questions about optimization passes. Answers to any > or all would be extremely helpful: > > How important are doInitialization/doFinalization? Most of the passes do not use them. > I can't detect any difference if I use them or not. Say, if you are writing

While checking on the status of https://llvm.org/bugs/show_bug.cgi?id=22657 in current llvm/clang trunk, I noticed that the previous work-around for recovering the missing in-lining of the c-ray 1.1 benchmarks of passing -mllvm -inline-threshold=500 no longer works. This regression doesn't exist in the 3.8.0 release. Any idea what commit in 3.9svn might have introduced this regression?

Hi, We want to apply the deepest possible inlining to the target code. Looks like builder.Inliner = createFunctionInliningPass(2000); does the sufficient inlining, but what would be the best value for threshold here? Apparently, builder.Inliner = createFunctionInliningPass(numeric_limits<int>::max()); gives less inlining, that 2000. Thanks, - D.

On Mon, 11 Jul 2005, Long Fei wrote: > > This didn't work as I tried with 197.parser. it works without > "-Wl,-disable-opt" switch though. > > [197.parser]$ llvm-gcc analyze-linkage.c and.c build-disjuncts.c > extract-links.c fast-match.c idiom.c main.c massage.c parse.c post-process.c > print.c prune.c read-dict.c utilities.c xalloc.c word-file.c

On 8/7/2017 1:02 PM, Daniel Berlin wrote: > Can someone fill me in on the issue with the dominator tree, > precisely, during inlining? > We now have the capability of quickly keeping it up to date without > too much trouble (it may require pushing it through a bunch of places, > but the actual changes to do should be easy). If I'm not mistaken (which I very well could be

I am modeling a trend surface using trmat and want to trim the resulting matrix to the area enclosed by my real data (i.e., remove all the extrapolated areas). I was using chull and in.chull to calculate the convex hull and change all the other values created by trmat to NA. However, my real data has portions that are slightly concave so chull would give me slivers that are extrapolations from

Stefan, Sounds like a brick process is not running. I have notice some strangeness in my lab when using RDMA, I often have to forcibly restart the brick process, often as in every single time I do a major operation, add a new volume, remove a volume, stop a volume, etc. gluster volume status <vol> Does any of the self heal daemons show N/A? If that's the case, try forcing a restart on

This didn't work as I tried with 197.parser. it works without "-Wl,-disable-opt" switch though. [197.parser]$ llvm-gcc analyze-linkage.c and.c build-disjuncts.c extract-links.c fast-match.c idiom.c main.c massage.c parse.c post-process.c print.c prune.c read-dict.c utilities.c xalloc.c word-file.c strncasecmp.c -Wa,-disable-opt -Wl,-disable-opt -lm -o llvm_parser [197.parser]$