search for: codified

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

...et of VorbisComments listed as part of the FLAC specification is justifiably inadequate for the purpose. A new set of recommendations for FLAC tags (in the VorbisComments format) is more than just desirable---it's essential for the future adaptation of FLAC for music distribution. A revised codified standard for VorbisComments or their equivalent is required. Since our project began three years ago, we have developed and are still working on the best means for tagging our files. We think we're just about there. We're in the process of finalizing our recommendations (in the form of...

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

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.

On Mon, Jun 15, 2020 at 4:05 PM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As another data point, the MLIR part of the codebase is pretty consistent on this: never use braces for trivial (single statement) if/else/for, but always put it on every branch if needed on any side of the if/else. Any opinion/stance policy/practice on the "one line, or one statement

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

I'm with Matt on this one. I much prefer the approach of ALWAYS use braces for ifs and for loops, even if they're not needed, for basically the same reasons as he put. The number of times I've added a statement inside an if without braces and forget to add them is annoyingly high, especially as it's not always an obvious error upfront. Similarly, being involved in a downstream

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