similar to: [LLVMdev] calling conventions and inlining

On Sun, 8 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: >>> but looking at the disassembly suggests that this might mainly be an issue >>> of x86 codegen, which is rather young as compared to other compilers. >> If you're testing on X86, I would be strongly suspious of the X86 backend,

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 Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > I see that you are objecting explicit inline control. > > The main problem is that inlining is absolutely crucial for some > "modern" programming styles. E.g. we use a huge collection of small C++ > template classes and template metaclasses, most of which have very > trivial and limited functionality (think of it

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

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

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 always_inline and > noinline, but maybe LLVM wants a finer grained level here) ? They really are different issues.

Are you suggesting that we have "always_inline" and "never_inline" keywoards that can be attributed to functions? If so, why do you want this level of control? What's wrong with the current inlining pass? Reid. On Sat, 2005-05-07 at 20:34 +0200, Markus F.X.J. Oberhumer wrote: > As I've just seen that there are some things going on w.r.t the long > needed

On Sun, 2005-05-08 at 02:52 +0200, Markus F.X.J. Oberhumer wrote: > Put simply, the inliner is too greedy and nice little leaf functions > suddenly run out of CPU registers. Even gcc 3.4 with -funit-at-a-time > started inlining too much, but at least I can tell gcc where to stop. > This whole noinline issue may be somewhat X86 specific, though. This is where a register allocator

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. >

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

Hi all, as suggested on the mailing list I have converted the updated LZO code into git, so please pull my "lzo-update" branch from git://github.com/markus-oberhumer/linux.git lzo-update You can browse the branch at https://github.com/markus-oberhumer/linux/compare/lzo-update I''d ask some official kernel maintainer for review and to push this into linux-next so that it

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

Markus, We are in the process of trying to make this happen. It's a matter of getting all the duckings lined up in a row. We finally resigned ourselves to the fact that we can't cvs/svn and maintain the sanity of FSF branches, Apple branches and LLVM branches. So, over the next few working days we are going to set up a nightly cron script to checkout the latest and greatest

On Feb 20, 2008, at 6:55 PM, Cristina Cifuentes wrote: > - in what part of the code tree is the internal linkage attribute > being set for library functions? Internalize pass (Transforms/IPO/Internalize.cpp) sets internal linkage if the function is not in export list. If you're using 'llvm- ld' try -disable-internalize. - Devang

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

Hi Markus, Thanks for this interesting patch! It looks okay to me, but our C/C++ Front End guru is away right now. I would rather defer to him on this patch. He might not get to it until next week so I just wanted to let you know that there might be a bit of a delay before this patch hits mainline. I've already committed your configure changes. Reid. On Wed, 2004-12-22 at 21:42, Markus

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

Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very