Graphite calls limit_scops() to ensure, that every SCoP contains a single surrounding loop, as graphite - at the moment - is not able to handle SCoPs with two outermost loops or a bb not contained in any loop. In theory that is possible without problems, only some little bugs are in the way. So fix the bugs, remove limit_scops() and make theory reality.
Created attachment 16505 [details] Fix loop_affine_expr to remove limit_scops () - This is a HACK looking for smarter solution Problem 1: Scalar evolution functions in loop limits and conditions have to be constant or affine to be allowed in a SCoP. During SCoP detection we check this with: if (evolution_function_is_invariant_p (scev, n) || evolution_function_is_affine_multivariate_p (scev, n)); in loop_affine_expr(). If this expression is true, it is allowed in a SCoP. But e.g. the constant expr "p_1 * p_2" is allow in a SCoP, but we can not represent it using the polyhedron model. The matrix would be p_1 p_2 Const x y z with x*p_1 + y*p_2 + z There is no way to represent p_1 * p_2, so we fail in scan_tree_for_params trying to generate the matrix. There are two solutions: 1. This expression is representable, if we introduce a new parameter p_3 = p_1 * p_2 and calculate it before the SCoP. 2. We detect this cases and do not allow them in any SCoP. I would like to start with solution two. Later on we can implement solution one. I attached a patch, that simply copies scan_tree_for_params() and returns true, if a expression can be handled by scan_tree_for_params() otherwise false. This works on polyhedron using -fgraphite, but seems not to be the cleanest solution. I would prefer to keep if (evolution_function_is_invariant_p (scev, n) || evolution_function_is_affine_multivariate_p (scev, n)); and add only && (no_multiplication_in_parameters (scev)).
I prefer the second solution: if (multiplication_in_parameters (n)) then insert a new parameter on the BB preceding the scop, and use force_gimple_operand to gimplify the sequence of stmts for n. This returns a sequence of stmts that you can insert on the src of the entry edge of the scop.
Created attachment 16511 [details] patch for solution 2 Patch as discussed at today's graphite call: detect multiplications of parameters, then gimplify and add new parameters for these multiplication expressions.
I would consider this at a very low priority right now: I'm thus marking it as enhancement level. If you can get a fix for this one that would be great, otherwise let's fix this one in GCC4.5. Sebastian
Subject: Re: [graphite] Remove limit_scops() workaround On Thu, 2008-12-11 at 21:13 +0000, spop at gcc dot gnu dot org wrote: > > ------- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 21:13 ------- > I would consider this at a very low priority right now: I'm thus marking it as > enhancement level. > If you can get a fix for this one that would be great, otherwise let's fix this > one in GCC4.5. Actually I would like to get this one out soon. But I am afraid, that there will show up new bugs. So lets stay fixing the current ones and get something working. My plan for this is: 1. Get nightly builds running 2. Get Polyhedron compiling correct and gcc bootstrapping with -fgraphite-identity. 3. Remove limit_scops() 4. Fix the bugs that where hidden before. See you Tobi
Fixed in r227567.