similar to: [LLVMdev] -time-passes output from llc

> > > Besides, the git-svn readonly bridge is a great solution for those who want > to use git > It seems to be a reasonable solution for those individuals who want to use git, but in my experience not for organizations that want to use git, e.g. have a local server with local branches, with many people banging on that while at the same time continuously merging the LLVM mainline

On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote: > >> Besides, the git-svn readonly bridge is a great solution for those who >> want to use git >> > > It seems to be a reasonable solution for those individuals who want to use > git, but in my experience not for organizations that want to use git, e.g. > have a local server with local

On Mon, Aug 16, 2010 at 7:42 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Aug 16, 2010, at 7:24 PM, Mark Lacey wrote: > > > I have read through the TableGen Fundamentals documentation and been > browsing various .td files. One thing that is not clear to me is where > things like $src1 (as in GR32:$src1) are defined, and what they mean. The > TableGen

David, A few comments. > Naming Upstream > --------------- > > The intial clone from upstream results in a git remote reference with > the rather unhelpful name of "origin." As more remote sources get > added, it is easy to forget what "origin" is. Therefore, add a remote > with a more descriptive name. > > git remote add llvm-upstream

Hello folks, I'm sure this has been asked many times, but is there current work on decreasing the time taken by the DAG-based instruction selector, or the other phases of llc? I am just beginning to dive into LLVM, and I am interested in compile-time reductions that do not reduce code quality dramatically. For example, simply switching on "-fast-isel" (roughly 17% drop in code

> > There is a git tool named "git-flow" that specifically supports this model > and it seems like it might fit the LLVM development model so I wanted to > point it out in case others had not seen it. Perhaps the more core > developers can comment more on its usefulness in the LLVM ecosystem. > > [1] http://nvie.com/posts/a-successful-git-branching-model/ > [2]

Mark Lacey <641 at rudkx.com> writes: > David, > > A few comments. >   > > Naming Upstream > --------------- > > The intial clone from upstream results in a git remote reference with > the rather unhelpful name of "origin."  As more remote sources get > added, it is easy to forget what "origin" is.  Therefore, add

Jason Kim <jasonwkim at google.com> writes: > On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote: > > Besides, the git-svn readonly bridge is a great solution for those who want to use git > >   It seems to be a reasonable solution for those individuals who > want to use git, but in my experience not for organizations that >

Hi, there are two issues wich cost me some time to figure out and maybe it made sense if someone put them into the documentation and / or wiki, because without these addressed my system ran pretty instable and wasn''t very usable. This applies to xen-3.0 and kernel 2.6.12.6-xen: 1) Networking issue With the default bridged setup, networking was quite flaky, e.g. samba access from dom0

One strategy I use for our flaky bots is to have them email me only. If the failure is real, then I forward the email to who ever I find on the blame list. For a flaky build, this is least you can do. For our flaky builds I know how and why they are flaky, some person that gets email does not. This is also a great motivator to help me know what is wrong, and how to fix it. By default, all new

Just to be up-front, I normally work on very small projects and I am very much a non-core LLVM developer (I'm the MicroBlaze backend maintainer). However, we have had success where I work using the git branching model described in [1] and [2]. There is a git tool named "git-flow" that specifically supports this model and it seems like it might fit the LLVM development model so I

> On Oct 7, 2015, at 3:28 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 7 October 2015 at 23:20, Chris Matthews <chris.matthews at apple.com> wrote: >> For instance, a build that fails with a ninja error, will say so, same with a >> svn failure or a Jenkins exception. > > Will these get mailed to developers? Or admins? Unfortunately, Jenkins

On 9 October 2015 at 19:02, David Blaikie <dblaikie at gmail.com> wrote: > Where "software" here is presumably the OS software Yes. This is the real noise, one that we cannot accept. > I think that misses the common usage of the term "flaky test" (or do the > tests themselves end up other (1) or (2)?) or flaky tests due to flaky > product code (hash

Hey all, Has anyone ever had problems with flaky behaviour when registering softphones dynamically with asterisk? I'm working with Kphone and having problems getting consistent results with registration. When Kphone is able to register, asterisk reports -- registered SIP '2001' at XXX.XXX.XXX.XXX port 5060 where asterisk sees [2001] in sip.conf as [2001]

According to https://reviews.llvm.org/D88348#2344466, that diff should fix the failure. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Fāng-ruì Sòng via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Fāng-ruì Sòng <maskray at google.com> Date: Tuesday, November 10, 2020 at 10:13 PM To: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Cc: Nico

Mark Lacey <641 at rudkx.com> writes: > git remote add llvm-upstream http://llvm.org/git/llvm.git master > > If the intent is to rename origin, this can be done directly: >   git remote rename origin llvm-upstream Much better. Thanks. > Updating LLVM - no local changes > -------------------------------- > > Splitting this into "no local

Hi Mark, This will workaround the problem of "default" branch restriction on the switch instruction. The trouble with this technique is that it will trump later optimization phases such as constant propagation. When a block was part of a case, because of the knowledge of the case value, the block was a candidate for better optimization. However, when we move the body of the case into

Thanks for taking a look. The flaky ASan test failure in the OP was stage1 so it sounds like there may be multiple problems :( -- Sean Silva On Sun, Jun 12, 2016 at 7:32 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > I threw all the sanitizers I had access to on this test and didn't > find anything. The merging uses threads so I can't rule out > nondeterminism.

Mine has been working well, but the only problem is that it doesn't support callerid (from the POTS side). > -----Original Message----- > From: John Schmerold [mailto:john@katy.com] > Sent: Tuesday, 5 August 2003 12:37 PM > To: asterisk-users@lists.digium.com > Subject: Re: [Asterisk-Users] Zhone Zplex 10 units > > Thanks for the Zplex heads up. > > Steven

Hello, I'm trying to minimize the processing time for llc -O3 by using a three step compilation process of 1. llc input.bc -stopafter=targetlibinfo -o input.mir 2. llc -run-pass={....min passes...} input.mir -o opt.mir 3. llc -startafter=machine-opt-remark-emitter -filetype=obj opt.mir -o final.obj Examining the passes produced by llc for O1,O2,O3 I compared (with XXX = {1,2,3}): llc