similar to: [LLVMdev] "Graphite" for llvm

On 12/27/09 10:18, ether wrote: > hi Tobi , > > that sounds greate :D > > On 2009-12-27 5:43, Tobias Grosser wrote: >> I already looked into implementing something like Graphite for LLVM. >> However just recently, so I have not released any code yet. As soon as >> some code is available I will post patches. > whats its status? do you need any help? Very

Tobias Grosser wrote: > The way to go is the scoplib format (propably extended by quantified > variables). This format could be extracted from graphite easily and > could also be created in LLVM. > What we need to get back into LLVM is only the new optimized schedule > described e.g. as cloog like scattering functions. These can be parsed > easily. The real code generation

On Thu, Aug 12, 2010 at 5:22 PM, Tobias Grosser <grosser at fim.uni-passau.de>wrote: > On 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > >> Dear guys, >> >> I am having problems to obtain good information from the LoopInfo. >> I am always getting a trip count of 0, even though I am clearly passing >> a loop with a constant bound. I am using

Hello all, I wanted to get some feedback on this patch for ScalarEvolution. It addresses a performance problem I am seeing for simple benchmark. Starting with this C code: 01: signed char foo(void) 02: { 03: const int count = 8000; 04: signed char result = 0; 05: int j; 06: 07: for (j = 0; j < count; ++j) { 08: result += (result_t)(3); 09: } 10: 11: return result; 12: } I

Dan, Thanks for the response ... On 12/17/2012 1:53 PM, Dan Gohman wrote: > On Mon, Dec 10, 2012 at 2:13 PM, Matthew Curtis <mcurtis at codeaurora.org> wrote: >> Hello all, >> >> I wanted to get some feedback on this patch for ScalarEvolution. >> >> It addresses a performance problem I am seeing for simple benchmark. >> >> Starting with this C

The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &A[0], i = 0; i != 300; i++ ) { I++;

On Mon, Dec 10, 2012 at 2:13 PM, Matthew Curtis <mcurtis at codeaurora.org> wrote: > Hello all, > > I wanted to get some feedback on this patch for ScalarEvolution. > > It addresses a performance problem I am seeing for simple benchmark. > > Starting with this C code: > > 01: signed char foo(void) > 02: { > 03: const int count = 8000; > 04: signed char

On 6 January 2011 15:16, Tobias Grosser <grosser at fim.uni-passau.de> wrote: >> The main idea is, we separate the transform passes and codegen passes >> for auto-parallelization and vectorization (Graphite[2] for gcc seems >> to taking similar approach for auto-vectorization). I agree with Ether. A two-stage vectorization would allow you to use the simple loop-unroller

hi Tobi , that sounds greate :D On 2009-12-27 5:43, Tobias Grosser wrote: > I already looked into implementing something like Graphite for LLVM. > However just recently, so I have not released any code yet. As soon as > some code is available I will post patches. whats its status? do you need any help? > A general plan to implement polyhedral transformations in LLVM: > > 1.

Hi, On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > Oh, I see... yes, we do stupid things involving mutating NoWrap flags after > a SCEV is created. (grep for setNoWrapFlags in ScalarEvolution.cpp.) That's really a compile time hack -- we defer some expensive tricks to prove nsw/nuw on an add recurrences to when we've been asked to

Hi Sanjoy, Thank you for looking into this! Yes, your patch does fix my larger test case too. My algorithm gets double performance improvement with the patch, as the loop now has a smaller instruction set and succeeds to unroll w/o any extra #pragma's. I also ran the LLVM tests against the patch. There are 6 new failures: Analysis/LoopAccessAnalysis/number-of-memchecks.ll

Hi ether, On 12/26/09 13:06, ether zhhb wrote: > hi, > > dose anyone going/planning to add something like > Graphite(http://gcc.gnu.org/wiki/Graphite) in gcc to llvm(or that > should be implement at the level of clang?)? I already looked into implementing something like Graphite for LLVM. However just recently, so I have not released any code yet. As soon as some code is

On Wed, 12 Sep 2012 14:18:43 +0200 Armin Größlinger <armin.groesslinger at uni-passau.de> wrote: > Hi, > > I had a few thoughts about recovering multi-dimensional accesses in > Polly and maybe it's time to share them. > > On 09/12/2012 10:38 AM, Tobias Grosser wrote: > > [...] Even in the last example which contains parameters both for > > the sizes and

On 01/06/2011 10:59 AM, Renato Golin wrote: > On 6 January 2011 15:16, Tobias Grosser<grosser at fim.uni-passau.de> wrote: >>> The main idea is, we separate the transform passes and codegen passes >>> for auto-parallelization and vectorization (Graphite[2] for gcc seems >>> to taking similar approach for auto-vectorization). > > I agree with Ether. >

Hi, Is it valid to query ScalarEvolution::getSCEVAtScope with a Value which is an Instruction inside the provided Loop? If so, I believe there is a bug in computeSCEVAtScope. Specifically: 04716     // If the scope is outside the addrec's loop, evaluate it by using the 04717     // loop exit value of the addrec. 04718     if (!AddRec->getLoop()->contains(L)) { 04719       // To

Nevermind. I misread the documentation. On Sat, Apr 30, 2011 at 8:12 PM, Thomas Jablin <tjablin at gmail.com> wrote: > Hi, > > Is it valid to query ScalarEvolution::getSCEVAtScope with a Value > which is an Instruction inside the provided Loop? If so, I believe > there is a bug in computeSCEVAtScope. Specifically: > > 04716     // If the scope is outside the

On Oct 12, 2009, at 3:46 AM, Prasenjit Chakraborty wrote: > > Hi, > How do I access the loop variables in a loop. > > for(i = 0; i < N; i++) > for(j = 0; j < M; j++) > A[i][j+k] = i + j; > > Is there anyway for me to know that in A[i][j+k], i & j are loop > variables > whereas k is not! The ScalarEvolution analysis can help here.

Hi Sanjoy, I have attached the IR I got by compiling with -O2. This is just before we widen the IV. To get the backedge taken count info I ran indvars on it and then replaced zext with sext. I think regardless of where we decide to add this transformation in the pipeline, it should try to preserve as much information as it can. This means that we should generate sext for signed IVs and

Hi Geoff, On Wed, Aug 9, 2017 at 8:58 AM, Geoff Berry <gberry at codeaurora.org> wrote: > On 8/8/2017 8:38 PM, Sanjoy Das wrote: >> >> Hi, >> >> On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> >> wrote: >>> >>> Oh, I see... yes, we do stupid things involving mutating NoWrap flags >>> after

On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: > On 11/08/2011 11:29 PM, Hal Finkel wrote: > > On Tue, 2011-11-08 at 20:24 +0100, Tobias Grosser wrote: > >> On 11/08/2011 03:36 PM, Hal Finkel wrote: > >>> On Tue, 2011-11-08 at 12:12 +0100, Tobias Grosser wrote: > >>>> On 11/08/2011 11:45 AM, Hal Finkel wrote: > > [A lot of performance