similar to: [LLVMdev] calling conventions and inlining

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] calling conventions and inlining"

2005 May 07
0
[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.
2005 May 07
0
[LLVMdev] calling conventions and inlining
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
2005 May 08
0
[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,
2005 May 07
0
[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
2005 May 07
0
[LLVMdev] calling conventions and inlining
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
2005 May 08
0
[LLVMdev] calling conventions and inlining
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
2005 May 07
2
[LLVMdev] calling conventions and inlining
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
2006 Mar 07
1
[LLVMdev] Selectively Disable Inlining for Functions
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. >
2008 Aug 25
0
[LLVMdev] Proposal : Function Notes
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 > > // > = > = > = > ----------------------------------------------------------------------= > ==// > //
2008 Aug 22
10
[LLVMdev] Proposal : Function Notes
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
2006 Mar 14
0
[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
2008 Aug 25
0
[LLVMdev] Proposal : Function Notes
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
2005 Feb 11
1
[LLVMdev] Function attributes and bytecode
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
2019 Nov 04
3
Fix clang's 'flatten' function attribute: add depth to always_inline?
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
2008 Aug 25
2
[LLVMdev] Proposal : Function Notes
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
2013 Jul 18
1
[LLVMdev] [RFC] add Function Attribute to disable optimization
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
2013 Jul 18
1
[LLVMdev] [cfe-dev] [RFC] add Function Attribute to disable optimization
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
2013 Jun 17
0
[LLVMdev] [cfe-dev] [RFC] add Function Attribute to disable optimization
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
2013 Jul 18
0
[LLVMdev] [RFC] add Function Attribute to disable optimization
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
2013 Jun 17
0
[LLVMdev] [RFC] add Function Attribute to disable optimization
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