search for: scevexpr

...cases. >I think this is the right idea, but probably the wrong place to put it. >I would put this into SCEVValidator::visitAddRecExpr. This function >always adds the AddRecExpr itself as a parameter, whenever it is found >to be parametric. However, what we should do is to create a new ScevExpr >that starts at zero and is otherwise identical. We then add this as a >parameter. When doing this, we now also need to keep all the parameters >that have been found previously in the base expression. A lot of Polly functions access ParameterIds and Parameters using existing ScevExpr. If...

Hi Sebastian, Recently, I found the "Polly - Calculate dependences" pass would lead to significant compile-time overhead when compiling some loop-intensive source code. Tobias told me you found similar problem as follows: http://llvm.org/bugs/show_bug.cgi?id=14240 My evaluation shows that "Polly - Calculate dependences" pass consumes 96.4% of total compile-time overhead

...or > the > array access in the new loop nest. Yes. This is very similar to what I had in mind and what I already started to implement. There are some slight differences: You create a map from the old_loop to a symbolic expression. What type would this symbolic expression have? Would it be a SCEVExpr? At the moment, we calculate at the beginning of each polly statement (a basic block) a value for each virtual induction variable of the original loops. For your example we get something like this. new_bb: new_iv_1 = add i32 c1, 0 new_iv_2 = add i32 c1, 7 new_iv_3 = add i32 c1, c2...

Tobias Grosser wrote: > You create a map from the old_loop to a symbolic expression. What type would > this symbolic expression have? Would it be a SCEVExpr? evaluateAtIteration takes a scev, so apply will take a scev, or a map (loop->scev). You can always build a ScevUnknown from an SSA name and use that in the apply. > At the moment, we calculate at the beginning of each > polly statement (a basic block) a value for each virtual induction...

On 07/29/2013 09:15 AM, Sven Verdoolaege wrote: > On Mon, Jul 29, 2013 at 07:37:14AM -0700, Tobias Grosser wrote: >> On 07/29/2013 03:18 AM, Sven Verdoolaege wrote: >>> On Sun, Jul 28, 2013 at 04:42:25PM -0700, Tobias Grosser wrote: >>>> Sven: In terms of making the behaviour of isl easier to understand, >>>> it may make sense to fail/assert in case

Hi Tobi, I would like to remove the SCEVRewriter code and replace it with a call to SCEVAddRec::apply (see attached a patch that adds just this function). More precisely I want to add another function called apply_map that applies a map (loop -> expr) on a given scev. This is the apply function on a multi-variate polynomial. So here is an overview of how I would like the scev code generator

...,128}<%for.cond2.preheader> p_2: {4,+,128}<%for.cond2.preheader> [...] The interesting observation is, that Polly introduces three parameters (p_0, p_1, p_2) for this SCoP, even though in the C source code only the variable 'i' is SCoP invariant. However, due to the way SCEVExpr(essions) in LLVM are nested, Polly sees three scop-invariant SCEVExpr(essions) which are all translated into independent parameters. However, as we can see, the only difference between the three parameters is a different constant in the base of the AddRecExpr. If we would just introduce p_0 (the...

...r> > p_2: {4,+,128}<%for.cond2.preheader> >[...] > >The interesting observation is, that Polly introduces three parameters >(p_0, p_1, p_2) for this SCoP, even though in the C source code only the >variable 'i' is SCoP invariant. However, due to the way >SCEVExpr(essions) in LLVM are nested, Polly sees three scop-invariant >SCEVExpr(essions) which are all translated into independent parameters. >However, as we can see, the only difference between the three >parameters is a different constant in the base of the AddRecExpr. If we >would just int...

...ven, no need to read all. Just search for your name. [..] >>The interesting observation is, that Polly introduces three parameters >>(p_0, p_1, p_2) for this SCoP, even though in the C source code only the >>variable 'i' is SCoP invariant. However, due to the way >>SCEVExpr(essions) in LLVM are nested, Polly sees three scop-invariant >>SCEVExpr(essions) which are all translated into independent parameters. >>However, as we can see, the only difference between the three >>parameters is a different constant in the base of the AddRecExpr. If we >>...

...ted for 8-bit and 16-bit induction variables commonly produces this pattern (on hexagon), where the add is performed as a 32-bit operation, but is preceeded by a truncate and zero-extend (or equivalent bitwise and). This change teaches ScalarEvolution to recognize this pattern and create the right SCEVExpr's so that the induction variable values can be computed at compile-time. --- include/llvm/Analysis/ScalarEvolution.h | 4 + lib/Analysis/ScalarEvolution.cpp | 69 +++++++++-- .../ScalarEvolution/2012-11-30-AddOfAnd.ll | 125 ++++++++++++++++++++ 3 fil...