Make pass-by-reference explicit by using pointer GMP's mpz_t automatically decays to pointer and IMath's mp_int is a pointer, therefore changing them in a function body always also changes the argument of the function's caller. With an isl_int implementation without pointer semantics (as in imath-32) this is not the case and the value change is not visible outside of the function. The parameter t of function row_cmp is allocated and free'd by its caller, hence we pass a pointer to its location instead the value itself. Otherwise, the value may get promoted to a big representation inside the function and the memory allocated in that conversion would not get freed, resulting in a memory leak. 8528f07 (Make pass-by-reference explicit by using pointers, Tue May 26 15:02:33 2015 +0200) fixed the same issue in the function isl_int_gcdext. Signed-off-by: Michael Kruse <isl@meinersbur.de> Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

isl_ast_build_node_from_schedule: generate disjunctions outside isolated part When an isolate option is being used, the parts of the schedule domain outside of the isolated part may be described using a disjunction. This disjunction then gets introduced into the executed relation and may end up getting generated at the leaves. Although there is some support for hoisting disjunctions up, this support is fairly limited. Moreover, if there are any extension nodes in between the isolation and the leaves, then the disjunction may not apply to the extension such that it cannot even be hoisted up. Generate the disjunction directly at the point of the isolation. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

isl_ast_codegen.c: build_ast_from_extension: only include simple hull of domain If the current generated domain contains any disjunctions, then intersecting the extension with the actual generated domain may needlessly introduce disjunctions which can complicate the generated code. In particular, this will happen when we introduce the disjunction implied by the pieces of the schedule domain that lie outside of some isolated part in the generated domain. Intersect the extension with the simple hull of the generated domain instead. Note that in exceptional cases, this may result in the generation of a subtree that does not execute any code. If this turns out to be a problem, then we may need to introduce additional tests to detect such situations beforehand. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

isl_ast_codegen.c: foreach_iteration: handle empty domain Although the set passed to foreach_iteration should never be empty, it may become empty after intersection with the build domain. Handle this case specifically since the default procedure of looking for a lower bound does not work on an empty set. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

isl_ast_graft_list_extract_shared_enforced: allow empty list of grafts We usually do not start generating a for node unless there are any statement instances that need to be executed by that for loop. It therefore makes sense to error out if it turns out such a situation occurs. However, it is perfectly possible to recover from such situations and so we might as well do that, even though the result will look somewhat awkward as it will contain an empty loop guarded by an "if (0)". Also, when we change build_ast_from_extension to only intersect the extension with the simple hull of generated domain in a subsequent commit, we may introduce such cases if (part of) the extension conflicts with the generated domain, but not with its simple hull. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

isl_ast_build_expr_from_set_internal: exploit earlier disjuncts When generating constraints for subsequent disjuncts, constraints that only serve to exclude earlier disjuncts do not need to be generated. We currently take the basic sets as they come. We may want to sort them first at some point. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

isl_ast_expr_from_aff: avoid extracting modulos with very large coefficients When looking for opportunities for writing an fdiv_q in terms of a modulo, we check the explicitly available constraints first. These constraints may include bounds on integer variables to the maximal value of some integer type. We do not want to use such constraints since the corresponding modulo expression will include this large constant value. With any luck, there is still another bound hidden in the constraints that does not have such a large constant term. For example, on the new test case, we would produce code like this for (int c2 = 0; c2 < -((-n + 2147483648) % 32) + 32; c2 += 1) for (int c3 = 0; c3 <= 31; c3 += 1) S_1(((-n + 2147483648) % 32) + n + c2 - 32, c1 + c3); because the upper bound on n is explicitly available in the constraints, while the lower bound on n has been eliminated because it is implied by other constraints. By rejecting the upper bound, the AST generator is forced to look for a lower bound on n and in the end produces for (int c2 = 0; c2 < n % 32; c2 += 1) for (int c3 = 0; c3 <= 31; c3 += 1) S_1(-((n - 1) % 32) + n + c2 - 1, c1 + c3); Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

isl_basic_map_simplify: remove integer coefficients from integer divisions If a variable has an integer coefficient inside the definition of an integer division, then it can safely be pulled out of the integer division. Do so to simplify the expression. It would be nice if we could perform this check only when there is some potential of finding integer coefficients, but unfortunately there are currently many places where an integer division is introduced or modified. Introducing integer divisions mainly happens inside set_div_from_lower_bound, but there are several places where affine expressions are plugged into div expressions, which may also result in integer coefficients in the result. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

add isl_multi_*_factor_range These functions complement the isl_multi_*_range_factor_range functions, which take a function in a map space as input, while these functions that a function in a set space as input. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>

add -std=gnu99 to compile flags when compiling imath-32 backend with gcc The imath-32 backend relies on the C99 behavior of "inline", which is different from the default gcc behavior, resulting in multiple definition errors when compiling the imath-32 backend with gcc. The original imath-32 support was developed on top of a patch that would end up setting -std=gnu99 for gcc, but this patch was dropped. Set -std=gnu99 explicitly when compiling the imath-32 backend with gcc. Reported-by: Tobias Grosser <tobias@grosser.es> Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>