search for: codify

On Wed, Sep 24, 2014 at 4:49 PM, Reid Kleckner <rnk at google.com> wrote: > +1 for a having a short leading sentence followed by a blank line. This is > always the email subject, so plan accordingly. > > IMO the rest doesn't matter and isn't worth codifying. > IMO, none of this is worth codifying really... We could certainly have a little guide for how to write awesome commit logs and point people at it. But this is one of (many) aspects of getting ramped up on the practices and patterns of the community. Not sure it ever really makes sense to...

Hello... For the last three years, several of us have been developing a FLAC-based digital music library for use at our radio station here in northern California. This was started first as an experimentwith the goal of understanding what it takes to make a useful library on a central network file server. In the process, we developed an improved and far more useful schema for tagging the

On 14 January 2013 12:27, henry miller <hank at millerfarm.com> wrote: > Would it be unreasonable to ask for a new/seperate set of optimizations: > optimize debug. This would apple agressive optimizations, but not > "significantly" changing the order of the code. > This will be interesting, but knowing how LLVM can segfault when commenting out one or the other pass

Renato Golin Linaro <renato.golin at linaro.org> writes: > I don't think you really need a performing debug image, though. Oh, you'd be surprised. We have hit many cases where debugging a completely unoptimized program is so slow it's not worth doing. Think about large parallel codes with millions of threads running on hundreds of thousands of sockets. Debugging even

On 14 January 2013 18:38, <dag at cray.com> wrote: > Debugging even minimally optimized code can be a huge productivity win. > Plus optimization tends to expose things like race conditions in > parallel codes. > That's what -O1 is for, isn't it? What I meant is that there is little need for an -O3-no-reorder optimization level. Maybe in extreme cases, but I

On 1/14/2013 3:09 AM, Chandler Carruth wrote: > > [...] This level should always produce > binaries at least as fast as quickopt, but they might be both slower to > compile. The "always" part cannot really be guaranteed or enforced. I'd state it in terms of intention, i.e. "this level is intended to produce binaries at least as fast as quickopt". Otherwise,

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

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"

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

Hi all- A few weeks ago I noticed that our "omit braces with single line blocks" rule wasn't written down! Additionally, as a group on IRC and in review, noticed that the enforcement of this rule has been extremely inconsistent. We made a first run at codifying our existing practice here: https://reviews.llvm.org/D80947, which was then committed after significant time on llvm-commits. I would like to encourage the list via discussion and further reviews/commits to come to a consensus on what we actually MEAN by this rule. For example, a recent commen...

On 1/14/2013 3:23 PM, Chandler Carruth wrote: > > This is a great question. My plan would be: 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. The problem is not so much with the inlining decisions, as much as it is with keeping the attributes in the inlined code.

...>> Hi all- >> >> >> >> A few weeks ago I noticed that our “omit braces with single line blocks” rule wasn’t written down! Additionally, as a group on IRC and in review, noticed that the enforcement of this rule has been extremely inconsistent. We made a first run at codifying our existing practice here: https://reviews.llvm.org/D80947, which was then committed after significant time on llvm-commits. >> >> >> >> I would like to encourage the list via discussion and further reviews/commits to come to a consensus on what we actually MEAN by this...

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 1/19/2013 1:55 AM, Chandler Carruth wrote: > > -ffast-math is *totally* different from these attributes, and in fact > -ffast-math is specifically not modeled as a function attribute because > it changes the fundamental semantics of an operation. It's not different at all. The user may want to compile parts of the program with -ffast-math, and parts without it. Same thing

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

...> wrote: > > Hi all- > > A few weeks ago I noticed that our “omit braces with single line blocks” > rule wasn’t written down! Additionally, as a group on IRC and in review, > noticed that the enforcement of this rule has been extremely inconsistent. > We made a first run at codifying our existing practice here: > https://reviews.llvm.org/D80947, which was then committed after > significant time on llvm-commits. > > I would like to encourage the list via discussion and further > reviews/commits to come to a consensus on what we actually MEAN by this > rule....

On 1/14/2013 4:57 PM, Chandler Carruth wrote: > > I absolutely think that when a function has an optimization attribute, > that applies to the code in the function and all code inlined into the > function. If foo calls bar then foo's optimization level should be valid > for bar, or bar should be marked noinline, or something else. That's going way too far. For example, if

On Jan 19, 2013, at 9:18 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/19/2013 1:55 AM, Chandler Carruth wrote: >> >> -ffast-math is *totally* different from these attributes, and in fact >> -ffast-math is specifically not modeled as a function attribute because >> it changes the fundamental semantics of an operation. > > It's not

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.

Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> writes: > I think braces should be added in all contexts, and the more contexts > the better. It eliminates any inconsistency or attempt to contextually > interpret rules. It also reduces merge conflicts, since something > eventually something will probably be added inside any control flow > statement. I’ve suffered