search for: recommited

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

On 19 Oct 2015, at 19:05, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I find the git imerge script extremely useful for this kind of situation. > > https://github.com/mhagger/git-imerge > > Logically, it does something similar to rebasing your local branch onto EVERY commit in the upstream branch, in turn, until it finds conflicts. There is

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 colleague submitted a patch that fixed the issue

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

On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote: > Trunk still has the different gcc and clang versions. > > What's worse, the 7.0.0 release has them too :-( I completely missed > this and we can't fix it for 7.0.1 since that would also be an ABI > break. > Is this something we could fix by adding a symbol alias to the linker script for libLLVM.so? -Tom >

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 >

+1 in general, and Philip has good suggestions as well! -- Mehdi On Sat, Nov 16, 2019 at 8:37 AM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > + 1 in general, a couple of suggestions > > On 11/14/19 7:46 PM, Finkel, Hal J. via llvm-dev wrote: > > Hi, everyone, > > > > I've been fielding an increasing number of questions about how our

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;