search for: zinovi

Seems that adding -extra-vectorizer-passes doesn't help to vectorizer in my case. LoopRotation re-run does nothing. 2014-10-15 2:54 GMT+04:00 Chandler Carruth <chandlerc at google.com>: > > On Tue, Oct 14, 2014 at 3:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> > I have and will continue to push >> > back on trying to add it until we at least

In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so and so LLVM doesn’t vectorize this loop even if we try to force it. The following loop will be vectorized if we force it: int foo(int * A, int * B, int n, int k) { for (int i = 0; i < 1024; ++i) A[i] += B[i*k]; } So will this loop: int foo(int * restrict A, int

Hi Robert, Can you ping the code owners about these patches. It might be good to write a separate email per code owner and cc the appropriate -commits list. Thanks, Tom On Wed, Apr 02, 2014 at 06:16:44PM +0400, Robert Khasanov wrote: > Hi Tom, > > I would like to nominate the following patches to be backported to 3.4.1 > > Clang: > 1. r204742 - Zinovy Nis <zinovy.nis at

Hi, I'm reading "http://llvm.org/docs/Vectorizers.html" and have few question. Hope someone has answers on it. The Loop Vectorizer can vectorize code that becomes a sequence of scalar instructions that scatter/gathers memory. ( http://llvm.org/docs/Vectorizers.html#scatter-gather) int foo(int *A, int *B, int n, int k) { for (int i = 0; i < n; ++i) A[i*7] += B[i*k]; } I

Hi, There's several, to my eyes, somewhat related looking bugs: Bug 36743 - Cannot select: X86ISD::CALL ICE with -mx32 -O2 -fno-plt https://bugs.llvm.org/show_bug.cgi?id=36743 Bug 34268 - JITting of x32 code on x64 fails with crash or instruction selection error. https://bugs.llvm.org/show_bug.cgi?id=34268 There's unfortunately been no investigation. I'm asking because I hit

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Zinovy Nis" <zinovy.nis at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "James Molloy" <james at jamesmolloy.co.uk>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Thursday, October 16, 2014

While reviewing a fix for maintaining loop metadata (http://reviews.llvm.org/D5539) I noticed that we make a strict assumption about the metadata being attached to the branch that is an immediate predecessor of the loop header. This does not work well with LLVM's approach of lazy critical edge splitting. I've proposed working around this with heroics inside the critical edges splitting

I've added a straw-man of some extra optimization passes that help specific benchmarks here or there by either preparing code better on the way into the vectorizer or cleaning up afterward. These are off by default until there is some consensus on the right path forward, but this way we can all test out the same set of flags, and collaborate on any tweaks to them. The primary principle here

I'm happy with any representation that works for optimizer. I can prepare a patch for clang to update the 'omp simd' and 'clang loop' CodeGen. We do not use LoopInfo in front-end, but it's no problem to go to the block's single predecessor and attach the metadata there. Regards, Alexander -----Original Message----- From: Tobias Grosser [mailto:tobias at grosser.es]

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,

> On Oct 14, 2014, at 8:53 AM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > > >> On Oct 13, 2014, at 5:56 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >> >> I've added a straw-man of some extra optimization passes that help specific benchmarks here or there by either preparing code better on the way into the vectorizer or cleaning

On Mar 12, 2014, at 4:05 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Mar 12, 2014 at 3:50 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so > > But, why? > > I'm moderately sure that neither C nor C++

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an