This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH] New Vectorizer APIs


Razya Ladelsky/Haifa/IBM wrote on 19/08/2008 11:03:45:

> Hi,
>
> This patch introduces new vectorizer functions that could be called
> from other passes,
> allowing the caller to obtain information about the vectorizability
> of a loop, or the
> costs of vectorizing it vs not vectorizing it.
>
...
>
> In order to test the above functions, I created an artificial pass
> running before
> the vectorizer, calling each one of the these functions.
> For sanity checking, I ran tests with this pass enabled; bootstrap
> and testsuite
> passed successfully for c, c++ and Fortran (i386-Linux).
>
> It is pretty straight forward, but here's what the main driver that I
used
> looks like:
>
> bool
> call_vect (void)
> {
>   struct loop *loop;
>   loop_iterator li;;
>   int scalar_cost, vect_cost;
>   tree t_scalar_cost, t_vect_cost;
>   FILE *saved_vect_dump=NULL;
>   if (vect_dump)
>    {
>     saved_vect_dump = vect_dump;
>     vect_dump = NULL;
>    }
>   FOR_EACH_LOOP (li, loop, 0)
>     {
>         loop_vectorizable_p (loop);
>         get_min_prof_iters (loop);;
>         get_int_sv_costs (loop, 10, &scalar_cost, &vect_cost);
>         get_tree_sv_costs (loop, build_int_cst (NULL_TREE, 22),
> &t_scalar_cost, &t_vect_cost);
>     }
>   vect_dump = saved_vect_dump;
>   return true;
> }
>

If we wanted to consider incorporating this patch to mainline, maybe we can
change this pass to do something with the information it computed
(something that we could also test, or anyhow something useful). One idea
is to guide the vectorizer which loop to vectorize: right now, given a
doubly-nested loop, the vectorizer chooses to vectorize the outer-loop
rather than the innermost loop. It would be nice if this pass could check
whether the expected impact of vectorizing a loop is higher than the
expected impact of vectorizing its enclosing outer-loop, and convey that
information to the vectorizer somehow. (Just a thought. The cost model for
outer-loop vectorization is quite poor currently, so I wouldn't rely on
this information too much...)

> Any comments or suggestions are welcome,

Just a few small comments/suggestions:

> +void vect_performance_improvement (loop_vec_info, int, struct
sv_result_costs *);
> +void vect_performance_improvement_2 (loop_vec_info, tree, struct
sv_result_costs *);
>
> +void get_int_sv_costs (struct loop *, int, int*, int*);
> +void get_tree_sv_costs (struct loop *, tree, tree*, tree*);

I think you can get rid of the duplicate implementations you have for
'vect_performance_improvement[2]' and 'get_[int/tree]_sv_costs' for
constants and non-constant argumetns. E.g., 'get_int_sv_costs' could just
be a wrapper to 'get_tree_sv_costs' (or rather 'get_sv_costs') that would
in addition do the int<->tree conversions (the content of these APIs is so
similar that it seems worth while to unify them, and I think the result
would be just as readable).

Also, since these are exposed to external users, I'd vote for a more
descriptive name ('get_scalar_and_vectorized_loop_costs' ?), and maybe also
add a 'get_vectorization_impact' API that computes the vectorization impact
(wrapper to 'get_scalar_and_vectorized_loop_costs' that returns scalar_cost
divided by vector_cost).

(Also the name of the function 'vect_performance_improvement' is maybe a
bit misleading - it looks like it just gathers the different costs and
records them; it doesn't do anything with them, like estimating performance
improvement, right?).

Lastly, about:

+int
+get_min_prof_iters (struct loop *loop)
+{
...
+..
+  loop_vinfo = vect_analyze_loop (loop);
+
...
+  prof_iter = vect_estimate_min_profitable_iters (loop_vinfo);
...
+  return prof_iter;
+}

Is there really a need to call 'vect_estimate_min_profitable_iters' again,
right after it was already just invoked during 'vect_analyze_loop'? Could
you instead take the value that was already computed and recorded in
loop_vinfo? (There are a few places in the vectorizer that do that, like
so:
 min_profitable_iters = LOOP_VINFO_COST_MODEL_MIN_ITERS (loop_vinfo);
 th = conservative_cost_threshold (loop_vinfo,min_profitable_iters);;


Other issues where raised separately, and are probably part of
future/on-going work (lighter weight analysis, additional finer APIs,
maintaining analyzed information instead of destroying it when this makes
sense, using these API's in real passes...).


thanks for the patch,

dorit

> Thanks,
> Razya
>
> ChangeLog:

>  * tree-vectorizer.h (costs, sv_result_costs): New structures.
>  (vect_performance_improvement, vect_performance_improvement_2,
>  loop_vectorizable_p, get_min_prof_iters, get_int_sv_costs,
>  get_tree_sv_costs): Declare new functions.
>  * tree-vect-analyze.c (compute_iterations, cost_iterations): New
variables.
>  (loop_vectorizable_p, get_min_prof_iters, get_int_sv_costs,
>  get_tree_sv_costs, vect_loop_niters): New functions.
>   (vect_compute_loop_niters): New function, replacing
vect_get_loop_niters..
>  (vect_get_loop_niters): Remove.
>  (vect_analyze_loop_form): Use compute_iterations.
>  * tree-vect-transform.c (scalar_vect_cost): New structure.
>  (vect_set_cost_parameters): New function.):
>  (vect_estimate_min_profitable_iters): Use vect_set_cost_parameters
>  to compute the cost parameters.
>  (vect_performance_improvement, vect_performance_improvement_2):
Newfunctions.

> [attachment "vect_cm_api.txt" deleted by Dorit Nuzman/Haifa/IBM]


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]