similar to: [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

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

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

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

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

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

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 >

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

On Sun, Sep 15, 2013 at 8:08 PM, Sean Silva <silvas at purdue.edu> wrote: > > > > On Sat, Sep 14, 2013 at 7:05 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <rkotler at mips.com> wrote: >> >>> Hi Chandler, >>> >>> What changes are you planning to make? >>>

> 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

Thanks for your reply. Compiler-rt was a problem. From the documentation I thought it was mandatory (so what is it used for?), but it was giving all those error about stdbool.h missing that I reported. Now things got better, but I have still problems. 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

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

Giorgio Franceschetti <g.franceschetti at vidya.it> writes: > I also tried to build LLVM with 3.3 sources. > Same problems. If you omit compiler-rt, does it work? (compiler-rt is not a required component.) > Even worse, Visual Studio hangs and I had to kill the process. > > What could it be? Is Visual Studio 2012 working with LLVM/clang? > > Or LLVM/Clang is not

Especially since we have support for per function code gen attributes now. -eric On Wed, Apr 24, 2013 at 3:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: > 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 >>

On Fri, Nov 13, 2015 at 6:16 AM, <Peter_Marshall at sn.scee.net> wrote: > Hi Paul, > > Sorry for the delay, I've been out of the office. > > I think this example shows that name matching does not always work: > > template<typename T> class A { > public: > A(T val); > private: > T x; > }; > > struct B { > typedef

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, Dec 9, 2015 at 10:40 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be > surprising if we used the typedef (or otherwise non-canonical) name in the > class name): > > > > Finally getting back to this….. Ha. We don't unwrap the typedefs ("name > as

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 least (all of the other compilers they use already support some form of this feature so it is very

On Thu, Jun 22, 2017 at 05:35:51PM +0000, David Blaikie wrote: > optnone should work, but really noinline should probably (Chandler: Can you > confirm: is it reasonable to model noinline as "no interprocedural analysis > across this function boundary" (so FunctionAttrs should do the same thing > for noinline as it does for optnone, for example? ie: not derive any new >