similar to: [LLVMdev] [cfe-dev] [PROPOSAL] per-function optimization level control

On 29 May 2013 09:28, <Andrea_DiBiagio at sn.scee.net> wrote: > Hi, > > I just wanted to bump this discussion in case anyone had any more comments > to make. > > We're in a bit of a bind here as we've now had requests for this feature > from 10 separate customers, so we're going to be required to implement > this feature somehow in our private branch at

Hi David, > Regarding Andrea's proposal -- the new #pragma can be useful (in rare > cases when there is a compiler bug), the intended use cases are > questionable: > 1) it should not be used as a mechanism to triage compiler bugs -- the > compiler backend should have mechanism to allow any pass to be > disabled for any (range of) function(s) via command line options so >

On Wed, May 29, 2013 at 10:17 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 29 May 2013 09:28, <Andrea_DiBiagio at sn.scee.net> wrote: > > Hi, > > > > I just wanted to bump this discussion in case anyone had any more > comments > > to make. > > > > We're in a bit of a bind here as we've now had requests for this

On Fri, Jun 14, 2013 at 4:06 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > Hi David, > >> Regarding Andrea's proposal -- the new #pragma can be useful (in rare >> cases when there is a compiler bug), the intended use cases are >> questionable: >> 1) it should not be used as a mechanism to triage compiler bugs -- the >> compiler backend should have

Hi Jonathan, > From: Jonathan Sauer <jonathan.sauer at gmx.de> > Have you looked at "Noise", presented at this year's European LLVM Conference? > > | Noise is a language extension that allows a programmer to create > custom optimization > | strategies and apply them to specific code segments. This enables > fine-grained control > | over the

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

Hello, We've had a high priority feature request from a number of our customers to provide per-function optimization in our Clang/LLVM compiler. I would be interested in working with the community to implement this. The idea is to allow the optimization level to be overridden for specific functions. The rest of this proposal is organized as follows: - Section 1. describes this new feature

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

Wouldn’t implementing this proposal be a red herring? By this I mean, it is possible that throughout the optimization phases, there is an implied assumption that all functions are similarly optimized. An example would be under certain optimization flag, compiler changes calling convention of static functions. - Fariborz On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote: >

Dropping opt level should not lead to ABI changes. Otherwise you won't be able to mix-match O2 and O0 objects either. David On Mon, Jun 17, 2013 at 10:59 AM, jahanian <fjahanian at apple.com> wrote: > Wouldn’t implementing this proposal be a red herring? By this I mean, it is > possible that > throughout the optimization phases, there is an implied assumption that all >

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

> Wasn't this already proposed? > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058112.html > > LLVM already has optsize. Maybe it's just a matter of hooking up gcc's > attr(optimize) to it in clang, as a first approximation. Looks like it, yes! Chandler, what were you thoughts on the pass manager? Should it select the set of passes for a function based on

In reply to the question about what would be the common use case: > What is the common use case? Making sure some funtion is always > optimized or making sure it never optimized? If the second one, I > wonder if marking it cold would be a good enough approximation. Although both cases would be nice and our users have expressed some interest in both, the critical one is the second case

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

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 opportunity to discuss the proposal with a number of people at and

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

Hello all, I've managed to trace an awkward bug down to the MSVC linker incorrectly merging llvm::OperandInfo constants between various backend targets I was linking in to my compiler executable. The bug manifested itself by replacing the operand data structures for target A with the data structures for target B. I have managed to work around this issue by moving the operand definitions

Hi Giorgio, > > I receive an error that seems related to the fact that the grep command > is missing. > > Is it possible? If grep is needed, how can I found it in Windows? > See here: http://clang.llvm.org/hacking.html#testingWindows grep (and a few other required tools) are in the GnuWin32 tools. Thanks, Greg Bedwell SN Systems - Sony Computer Entertainment Group

On Wed, Apr 24, 2013 at 6:00 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > Hello, > > We've had a high priority feature request from a number of our customers > to > provide per-function optimization in our Clang/LLVM compiler. > I would be interested in working with the community to implement this. > The idea is to allow the optimization level to be overridden >

GCC's optimize attribute should work fine (at least with trunk): __attribute__((optimize("O3","no-tree-pre"))) int foo( ...) { ... } will turn on -O3 for 'foo', but disable PRE pass for it. If you see any problems there, you should file a bug. Regarding Andrea's proposal -- the new #pragma can be useful (in rare cases when there is a compiler bug), the