similar to: [LLVMdev] Selectively Disable Inlining for Functions

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

Hi Alastair, > Forgive my confusion, but I can't help notice that LangRef states: > > Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be

Hi Duncan- Forgive my confusion, but I can't help notice that LangRef states: Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be discarded. Why

Dear All, I was wondering if there is a standard way of specifying a list of functions that *should not* be inlined by the -inline pass. 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

On Mon, 6 Mar 2006, John Criswell wrote: > I was wondering if there is a standard way of specifying a list of functions > that *should not* be inlined by the -inline pass. Nope, but you could hack something into gccas/gccld if you want. Of course, you can disable inlining completely with the -disable-inlining flag. > I'm currently working with an experimental analysis pass that

Good evening, Kenneth. Thank you to apply (and rewrite my naive code better) and to file the issue to http://llvm.org/bugs/show_bug.cgi?id=7304 I have checked r105528 at this morning. I think the pass must be still cleaned up and rewritten. There are my two proposals for enhancement. 1) To separate Specialization(and rewriting callsites) to other module. It would be better if new module were

On Tue, 7 Mar 2006, Vikram S. Adve wrote: > Changing the heuristics directly would have to be a custom change (i.e., > couldn't be checked in). Is there a way for a client pass or tool to > influence the heuristics? If not, does it make sense to add such a > mechanism? To be clear, I'll restate my position here, then follow up with more specifics of such a mechanism to

On Mar 6, 2006, at 4:05 PM, Chris Lattner wrote: > On Mon, 6 Mar 2006, John Criswell wrote: >> I was wondering if there is a standard way of specifying a list of >> functions that *should not* be inlined by the -inline pass. > > Nope, but you could hack something into gccas/gccld if you want. > Of course, you can disable inlining completely with the -disable- >

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

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

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

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

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

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 Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In