search for: noncanonic

...r than as they apply to the problem at hand. > > - I agree that promotion to 64-bit loses information and should only be done when target information tells us that it's good for codegen. > > - I personally have no problem using "indvars" as a codegen prepare pass for any noncanonical target-specific transforms that require SCEV. The only canonicalization that it usually accomplishes that is replacement of loop exit values. The sign/zero extend elimination (widening) and LFTR are really codegen optimizations that should be defered until the last round of loop opts. I don't...

So, I know there are a lot of mixed feelings about NSW and NUW, but I'm running into a common pattern where they really help: void f(char *array, int i) { // do some stuff... g(array[i++]); // do some more stuff... g(array[i++]); // more of the same } So, this kind of code comes up pretty frequently. Unrolled loops with an int IV[1], encoding, decoding, compression, etc. What

...gist of this question, but I want to refine the trade-off a bit. With a monorepo, downstream single-project users actually have two options. They can work off the mirrors, or they can just download the whole thing. So with the monorepo, downstream single-project users are not forced to work off noncanonical mirrors. They are only "forced" to do so if they are unable or unwilling to download a 500mb repo and throw away most of it. Which I think may actually be relatively few people. But what do I know? Anyway my answer to this question has been and still is, that a monorepo is strictly...

...want to refine the > trade-off a bit. > > With a monorepo, downstream single-project users actually have two > options. They can work off the mirrors, or they can just download the > whole thing. So with the monorepo, downstream single-project users > are not forced to work off noncanonical mirrors. They are only > "forced" to do so if they are unable or unwilling to download a 500mb > repo and throw away most of it. Which I think may actually be > relatively few people. But what do I know? I think we have evidence that many of our projects are used in isolati...

...gt; trade-off a bit. >> >> With a monorepo, downstream single-project users actually have two >> options. They can work off the mirrors, or they can just download the >> whole thing. So with the monorepo, downstream single-project users >> are not forced to work off noncanonical mirrors. They are only >> "forced" to do so if they are unable or unwilling to download a 500mb >> repo and throw away most of it. Which I think may actually be >> relatively few people. But what do I know? >> >> >> I think we have evidence that...

> On Jul 28, 2016, at 10:53 AM, Justin Lebar <jlebar at google.com> wrote: > > Thanks again for your thoughts, Chris. > >> As a straw man I would suggest the following criteria for inclusion into the mono-repo: >> >> (1) Projects in the mono-repo must be tightly coupled to specific versions or commits of other projects in the mono-repo > > I'm fine

Hi Duncan, > […] > 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked. > > 3. For many (most?) developers, changing to a monolithic git repo is a *bigger* workflow change than switching to separate git repos. Many people (and at least some