similar to: [LLVMdev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang

If I understand the attributes correctly, they would be function-level attributes applied to IR functions, correct? I'm curious what the semantics would be for cross-function optimization. For example, consider a function "foo" defined with maxopt and a function "bar" defined with optsize. If foo() calls bar() and the inliner wants to inline bar() into foo(), is that

Sent from my iPad On Jan 14, 2013, at 1:09 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > This has been an idea floating around in my head for a while and after several discussions with others it continues to hold up so I thought I would mail it out. Sorry for cross posting to both lists, but this is an issue that would significantly impact both LLVM and Clang. > >

On Mon, Jan 14, 2013 at 10:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > > Sent from my iPad > > On Jan 14, 2013, at 1:09 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > > This has been an idea floating around in my head for a while and after > several discussions with others it continues to hold up so I thought I > would mail it out.

Would it be possible to have a parameterised attribute? opt(min), opt(size), opt(max) ? On 14 January 2013 12:46, Justin Holewinski <justin.holewinski at gmail.com>wrote: > If I understand the attributes correctly, they would be function-level > attributes applied to IR functions, correct? I'm curious what the > semantics would be for cross-function optimization. For

On Mon, Jan 14, 2013 at 4:46 AM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > If I understand the attributes correctly, they would be function-level > attributes applied to IR functions, correct? I'm curious what the > semantics would be for cross-function optimization. For example, consider > a function "foo" defined with maxopt and a function

Sent from my iPad On Jan 14, 2013, at 11:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > On Mon, Jan 14, 2013 at 10:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >> >> Sent from my iPad >> >> On Jan 14, 2013, at 1:09 AM, Chandler Carruth <chandlerc at gmail.com> wrote: >> >> > This has been an idea floating

As a user I like this it is hard to understand what each level does. I know projects that are using O3 because 'more must be better'. I don't know how to explain that it might be slower, and measuring performance is tricky. (Many programs do multpile things, and spend most of their time waiting on the event loop) Would it be unreasonable to ask for a new/seperate set of

Chandler Carruth <chandlerc at gmail.com> writes: > minsizeopt > sizeopt > quickopt > opt > maxopt I prefer being consistent and putting "opt" at the end. I would still like something other than "opt" for the fourth one. "opt" seems too generic given the other levels. -David

Chandler Carruth <chandlerc at gmail.com> writes: > 4) Good, well-balanced optimizations, or '-O2' > - Attribute: opt (new attribute) Since all other levels have a qualifier, I'd suggest we do that here as well. Perhaps balancedopt? > 5) Optimize to the max or '-O3' > - Attribute: maxopt (new attribute) > - Goal: produce the fastest binary possible.

On Mon, Jan 14, 2013 at 1:30 PM, <dag at cray.com> wrote: > Chandler Carruth <chandlerc at gmail.com> writes: > > > minsizeopt > > sizeopt > > quickopt > > opt > > maxopt > > I prefer being consistent and putting "opt" at the end. > > I would still like something other than "opt" for the fourth one. "opt"

On Mon, Jan 14, 2013 at 2:07 PM, Christopher Jefferson < chris at bubblescope.net> wrote: > > 3) Optimize quickly or '-O1' > > - Attribute: quickopt (this would be a new attribute) > > - Goal: Perform basic optimizations to improve both performance and > simplicity of the code, but perform them *quickly*. > > This level is all about compile time, but in a

On 14 Jan 2013 09:10, "Chandler Carruth" <chandlerc at gmail.com> wrote: > > This has been an idea floating around in my head for a while and after several discussions with others it continues to hold up so I thought I would mail it out. Sorry for cross posting to both lists, but this is an issue that would significantly impact both LLVM and Clang. > > > 3) Optimize

Right now we have a healthy mixture of two ways to respond to -Oz and -Os in LLVM: 1) Pass this info to the PassManagerBuilder and then toggle some flag to the pass to change thresholds. 2) When running over IR, inspect it for the minsize or optsize attribute. Regardless of the particulars of what these mean and/or how they relate to -O2 vs -O3 for example, I'd really like to at least get to

Hi, On 08/07/2015 10:30 PM, Nick Lewycky wrote: [...] > Depends. What is the exact declaration of format_long? > > > In the input .ll file it is: > > ; Function Attrs: minsize optsize > define internal i16 @format_long(i16* %res.8.par, i16 %base.9.par, > i32 %x.10.par) #3 { > > which is later changed somewhere in opt to: > > ;

On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > >

On 08/07/2015 01:53 PM, Caldarale, Charles R wrote: >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] >> On Behalf Of Mikael Holmén via llvm-dev >> Subject: [llvm-dev] load instruction erroneously removed by GVN > >> But between the load and the alloca there is also >> call fastcc void @format_long(i16* %_tmp30, i16 10, i32 10), !dbg !22 >>

Hi Joan, On Mon, 13 May 2019 at 18:01, Joan Lluch <joan.lluch at icloud.com> wrote: > After looking at it a bit further, I think this is a Clang thing. Clang issues “align 2” if the struct has at least one int (2 bytes), but also if the entire struct size is multiple of 2. For example a struct with 4 char members. In these cases the LLVM backend correctly creates word sized load/stores

> On Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com> wrote: > > On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> Isn’t the problem the fact that the patch makes it harder for a target to >> get the generic code to reach its custom hook? >> Now the "cheap pow2 sdiv” is merged with the generic

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

I don't know of a way to do it from the command-line, but if you're willing to change the IR, you can add the optsize (for -Os) or minsize (for -Oz) IR attribute to the function you're compiling. On Fri, Sep 2, 2016 at 5:59 AM, Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Idle question, if anyone is reading still ... how do you get llc to do -Os > or