similar to: [LLVMdev] calling conventions and inlining

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

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

Hi Devang, I have a few questions below. On Aug 22, 2008, at 4:40 PM, Devang Patel wrote: > Here is a proposal that I mentioned sometime ago. Any > thoughts,comments or > suggestions on this proposal would be appreciated. > - > Devang > > // > = > = > = > ----------------------------------------------------------------------= > ==// > //

Here is a proposal that I mentioned sometime ago. Any thoughts,comments or suggestions on this proposal would be appreciated. - Devang // = = =---------------------------------------------------------------------- ===// // Function Notes (or Traits) // = = =---------------------------------------------------------------------- ===// This document describes the

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 Aug 22, 2008, at 4:40 PM, Devang Patel wrote: > The LLVM passes are responsible to take appropriate actions based on > Function > Notes associated with function definition. For example, > > define void @fn1() notes("opt-size=1") { ... } > > The function fn1() is being optimized for size without losing > significant > performance. The inliner will

On Thursday 10 February 2005 21:47, Markus F.X.J. Oberhumer wrote: > In order to get more familiar with the llvm sources I've recently > decided to try to add support for the always_inline and noline function > attributes. I believe it is better to let the compiler decide when or not to inline a function. Most of the times a developer goes overboard with inlining and ends up with a

Hi everyone, clang currently implements the 'flatten' function attribute by marking all calls to not 'noinline' functions with 'always_inline'. In effect, only the first level of calls is inlined, not all calls recursively (like gcc does). We briefly discussed possible solutions on IRC: We could add an equivalent LLVM attribute for functions (e.g. 'flatten'). The

On Aug 25, 2008, at 3:24 PM, Nick Kledzik wrote: > > On Aug 22, 2008, at 4:40 PM, Devang Patel wrote: > >> The LLVM passes are responsible to take appropriate actions based >> on Function >> Notes associated with function definition. For example, >> >> define void @fn1() notes("opt-size=1") { ... } >> >> The function fn1() is being

Andrea_DiBiagio at sn.scee.net wrote: > So.. > I have investigated more on how a new function attribute to disable > optimization on a per-function basis could be implemented. > At the current state, with the lack of specific support from the pass > managers I found two big problems when trying to implement a prototype > implementation of the new attribute. > > Here are the

On Thu, Jul 18, 2013 at 8:23 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > So.. > I have investigated more on how a new function attribute to disable > optimization on a per-function basis could be implemented. > At the current state, with the lack of specific support from the pass > managers I found two big problems when trying to implement a prototype > implementation of

On Jun 17, 2013, at 11:57 AM, Xinliang David Li <xinliangli at gmail.com> wrote: > Dropping opt level should not lead to ABI changes. Otherwise you won't > be able to mix-match O2 and O0 objects either. I was referring to “static functions”. Not that it happens, but something to consider. - Fariborz > > David > > On Mon, Jun 17, 2013 at 10:59 AM, jahanian

So.. I have investigated more on how a new function attribute to disable optimization on a per-function basis could be implemented. At the current state, with the lack of specific support from the pass managers I found two big problems when trying to implement a prototype implementation of the new attribute. Here are the problems found: 1) It is not safe to disable some transform passes in the

Andrea_DiBiagio at sn.scee.net wrote: > Hi, > > I previously made a proposal for adding a pragma for per-function > optimization level control due to a number of requests from our customers > (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for > the previous discussion), however the discussion was inconclusive. Some > of my colleagues recently had the