search for: sizeopt

...inlining doesn't impact the attributes. The inliner will be free to look at both the caller and the callee's attributes to choose the best inlining decision. > > Also, a nit-pick: can we make the naming consistent? It feels a bit > weird to have maxOPT and OPTsize. Perhaps use sizeopt and minsizeopt, or > optmax and optquick? Meh. I don't care really. It would require changing existing attributes, but we can do that. I think the most readable structure is the first: minsizeopt sizeopt quickopt opt maxopt I'd like to hear some support for one or the other of these...

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

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" > seems too generic given the other levels. >...

...that legal? If so, that may cause odd effects as you may perform expensive optimizations later on the inlined version of bar(), even though the original function is marked optsize. Also, a nit-pick: can we make the naming consistent? It feels a bit weird to have maxOPT and OPTsize. Perhaps use sizeopt and minsizeopt, or optmax and optquick? On Mon, Jan 14, 2013 at 4: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 i...

On Mon, Jan 14, 2013 at 1:46 PM, Kaelyn Uhrain <rikka at google.com> wrote: > 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" >> seems too g...

...may cause odd effects as you may perform > expensive optimizations later on the inlined version of bar(), even though > the original function is marked optsize. > > Also, a nit-pick: can we make the naming consistent? It feels a bit > weird to have maxOPT and OPTsize. Perhaps use sizeopt and minsizeopt, or > optmax and optquick? > > > On Mon, Jan 14, 2013 at 4: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...

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. Essentially, LLVM provides canned optimization "levels" for frontends to re-use. This is nothing new. However, we