similar to: [LLVMdev] calling conventions and inlining

There is one case where inlining/not-inlining affects correctness. A function which uses alloca() will behave differently in the two cases. You can argue one shouldn't write code like this, but it is legal. Chris Lattner wrote: > On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > >> I see that you are objecting explicit inline control. >> >> The main problem is

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 Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > Actually I feel that the current state of the art of inlining is where > register allocation has been about 10 years ago. It's pretty fine for most > things, but back then I remember writing code like "register const char *p > __asm__("%esi");" where just adding the explicit __asm__ boosted performance

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]$

On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> As I've just seen that there are some things going on w.r.t the long >>> needed implementation of calling conventions, may I also ask if it's >>> possible to address inlining at the same moment (i.e. attributes

I am investigating some inlining issue, so I did llvm-gcc aaa.c bbb.c ... nnn.c -o output opt -inline -inline-threshold=xxx < output.bc | llc -march=c > output_inline.c 1) I noticed that even if I set xxx to 0 or even a very small negative number, many functions are eliminated. I am wondering if these functions are inlined by the frontend, or identified as deadcode. For instance,

On Tue, 7 Mar 2006, Markus F.X.J. Oberhumer wrote: >> I'm currently working with an experimental analysis pass that checks for >> calls to memory allocation functions; inlining and dead code elimination >> might make the pass more stable, but we don't want to inline the calls to >> the memory allocation functions until after our analysis pass is finished. >

Long Fei wrote: > > I am investigating some inlining issue, so I did > > llvm-gcc aaa.c bbb.c ... nnn.c -o output > opt -inline -inline-threshold=xxx < output.bc | llc -march=c > > output_inline.c I am unsure of whether the LLVM GCC frontend does any inlining. However, I do know that your methods above run the LLVM inlining pass, albeit indirectly. If you use

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

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

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.

Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes: > No tests fail with the patch below, so I would say it's pretty useless. It > seems that the C bindings are the only user but we can probably just have them > return IPSCCP instead. I don't necessarily think your conclusion is wrong, but the patch isn't proving what you think it's proving. In fact, the

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,

David Vandevoorde a écrit : > > I don't think those are _good_ reasons though: If one doesn't want a C+ > + function to be inlined, one shouldn't define it inline. > > You must not have written a lot of C++ template then. You don't have the choice in this case, just check your STL header. > > FWIW, I've been involved in a couple of attempts by

On 8/4/2017 2:06 PM, Daniel Berlin wrote: > A few notes: > I'm a bit surprised IPO copy/constant propagation doesn't get this > case, but i didn't look if the lattice supports variables. > In particular, in your example, given no other call sites, it should > eliminate the dead code. > (In a real program, it may require cloning). In the actual program

On Tue, 7 Mar 2006, Markus F.X.J. Oberhumer wrote: > Still, my approach makes the inline hint a first-class property of an LLVM > function just like the calling convention, including preserving full source > code information. Preserving full source code information isn't a goal of LLVM, at least if you don't count debug information. :) > Most of the patch is actually

Reid Kleckner wrote: > I'm assuming this attribute won't affect inlining or other IPO in any > way, but you should probably mention that in the langref. To directly answer this, this is just a *mechanism* to implement linkonce_odr type linkage. This in itself does not imply in IPO restrictions, that should come directly from the linkage type. -- Sanjoy

I am interested in analyzing the bytecode code produced for C files. By default, inlining of user and library functions (libc) is done. If I turn off inlining (-disable-inlining in gccas and gccld) then no inlining is done. I want to be able to inline user code but disallow library code to be inlined. In trying to understand the InlineSimple.cpp code, I see that library functions are

All, I'm working on an improvement to the inline cost model, but I'm unsure how to proceed. Let me begin by first describing the problem I'm trying to solve. Consider the following pseudo C code: *typedef struct element { unsigned idx; } element_t; * *static inline unsigned char fn2 (element_t *dst_ptr, const element_t *a_ptr, const element_t *b_ptr,

On Aug 26, 2009, at 12:01 PM, Devang Patel wrote: >>> I do not understand how the "inlinehint" will help. How will it >>> influence the inliner ? >> >> The hint should make it more attractive to inline. I don't know >> the details >> yet and they will require some experimenting. >> > > In that case you want to add hint to A