search for: recommitted

Dear All, Please don't kill me. I've accidentally removed the directory /home/vadve/shared/PublicCVS/llvm-test/MultiSource/Benchmarks/MiBench from the LLVM Test CVS repository. I can either have our IT people restore it off of backup, or if someone has an updated copy of it, they can re-commit all the files. If you can recommit the files, please email me and do so. Otherwise, I'll

...by the third time I’d had to fix them, I was getting pretty good at it. I don’t wish to change the policy with regard to reverts (having a working and stable head is very valuable), but it would be good if we could have a stronger policy that stuff that is reverted goes into Phabricator and is not recommitted until the person who initially reverted it has signed off (or, at least, there’s a strong consensus that it’s the right thing). The main lesson for me is that more frequent merges will be less painful. That’s a big change, because previously I’d spend a day or two fixing merge conflicts no matter...

I see we're missing an isel pattern for add producing carry and doing a memory RMW. I'm going to see if adding that helps anything. ~Craig On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yes. I'm seeing that as well. Not clear what's going on. > > In any case it looks to be unrelated to the alias analysis so barring

Just be aware that those ifdefs were recommitted and reverted several times, so I'm not sure what the state is. On Fri, Sep 28, 2018 at 8:48 AM Alastair Murray via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kern, > > We also had issues with mixing GCC/Clang builds when testing the 7.0 > release branch. > > My...

This patch only results in relaxing dependencies. This now *allows* new orderings that were not previously allowed, but, the fact that we then actually get such a suboptimal output likely indicates an issue elsewhere, that this allowance is exacerbating. Some observations: 1. For some reason, memop folding seems to be generating seriously non-optimal instructions. It is somehow causing there to

On 15 March 2017 at 14:58, Hal Finkel <hfinkel at anl.gov> wrote: > When you reverted r282259 in 282289, you also reverted the functional fix > to make the command-line option actually work. Right now it is broken. > Regardless of what else we do, we should fix this (we should probably > recommit r282259, with the default flipped, to pick up the fixes). We should run check-all

Hi Evgeny, Quentin and Matthias found it was a problem about subreg live range update and will push a fix soon (http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170123/424126.html). Thanks, Wei. On Fri, Jan 27, 2017 at 10:35 AM, Wei Mi <wmi at google.com> wrote: > Sure. Will keep you posted. > > Thanks, > Wei. > > On Fri, Jan 27, 2017 at 10:31 AM, Evgeny

No objections here. I'd be glad to see this go in. :) - Lang. On Fri, Jul 18, 2014 at 4:30 PM, Eric Christopher <echristo at gmail.com> wrote: > Sounds like we've got sufficient amount of momentum here for Dave to > go ahead and recommit. Any last objections? > > -eric > > On Fri, Jul 18, 2014 at 1:35 PM, Eli Bendersky <eliben at google.com> wrote: >

Hi all, Memory fold tables: Two way mapping of each register-form instruction to its corresponding memory-form instruction. E.g. Mapping 'X86::ADD32rr' to 'X86::ADD32rm'. Few months ago I started an effort to auto-generate the X86 memory folding tables currently held under lib/Target/X86/X86InstInfo.cpp as huge manually-maintained static arrays. Automating the tables would reduce

Thanks for your replies. That was a very useful discussion. I won't recommit on a Friday afternoon, but will do on Monday, as it looks like we agreed again on the direction and the change. Orthogonal to this change, the interesting topics brought up are improved diagnostics, and the cases the vectoriser misses. I will briefly look why this particular case isn't vectorised, but I suspect

Hi Michael and Florian, ( + llvm-dev for visibility) I would like to quickly follow up on "Pragma vectorize_width() implies vectorize(enable)", which got reverted with commit 858a1ae for 2 reasons, see also that revert commit message. Ignore the assert, that's been fixed now. The other thing is that with the patch behaviour is slightly changed and we could get a diagnostic we

Hi everyone, In the reviewing system, after a patch is approved, what should be the following step? I assume I'll have to make sure the patch hasn't broken anything, before pushing it, so I'll wan't to run a full build+tests, probably in a remote sterile environment (like a jenkins server). Do we have an integration system like this? Or should I just trust the build+tests on my

...a symbol alias to the linker script for libLLVM.so? -Tom > Alastair, if you noticed this during the release testing, did you > surface it anywhere? > > > On Fri, Sep 28, 2018 at 6:07 PM, Reid Kleckner <rnk at google.com> wrote: >> Just be aware that those ifdefs were recommitted and reverted several times, >> so I'm not sure what the state is. >> >> On Fri, Sep 28, 2018 at 8:48 AM Alastair Murray via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi Kern, >>> >>> We also had issues with mixing G...

Folks, I've been asking around people about the state of FP contract, which seems to be "on" but it's not really behaving like it, at least not as I would expect: int foo(float a, float b, float c) { return a*b+c; } $ clang -target aarch64-linux-gnu -O2 -S fma.c -ffp-contract=on -o - (...) fmul s0, s0, s1 fadd s0, s0, s2 (...) $ clang -target aarch64-linux-gnu -O2 -S fma.c

Why are you reverting patches for any area that you have no authorization for ? No build was broken. This patch is fine. I am authorized to check in to the Mips area and Daniel is the maintainer for that area. On 06/08/2014 02:13 AM, Alp Toker wrote: > Author: alp > Date: Sun Jun 8 04:13:42 2014 > New Revision: 210424 > > URL:

On Fri, Jul 18, 2014 at 12:06 PM, Jordan Rose <jordan_rose at apple.com> wrote: > I don't have much to add here besides +1. I think using std::unique_ptr > even for create* functions/methods is the right way to go. +1 smart pointers here are a win in terms of safety and self-documentation. I don't see why create* factories should be treated differently. Eli >

...tor or email. There > is a strong expectation that authors respond promptly to post commit > feedback and address it. Failure to do so is cause for the patch to be > reverted. If substantial problems are identified, it is expected that > the patch is reverted, fixed offline, and then recommitted (possibly > after further review.) > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part -------------- An HTML attachment was sc...

John, Just get it restored from backups -- they don't take long to do it and it will preserve the logs. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Jan 9, 2007, at 5:23 PM, John Criswell wrote: > Dear All, > > Please don't kill me. > > I've accidentally removed the directory >

A couple people asked me when it is ok to revert a patch. The LLVM project uses a very aggressive form of code review. It is basically built on the assumption that people do the right thing most of the time, and optimizes for that case. However, people do make mistakes. When something bad happens, don't be shy about reverting a broken patch, particularly when it is an obvious problem.

There is a second issue with the new TableGenBackendSkeleton.cpp file. It is a skeleton file for writing a new TableGen backend. /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm/llvm/lib/TableGen/TableGenBackendSkeleton.cpp:38:17: error: private field 'Records' is not used [-Werror,-Wunused-private-field] RecordKeeper &Records;