This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A question about loop ivopt
- From: Zdenek Dvorak <rakdver at iuuk dot mff dot cuni dot cz>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Jiangning Liu <jiangning dot liu at arm dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 15 May 2012 12:18:36 +0200
- Subject: Re: A question about loop ivopt
- References: <4fb1e3c9.6aa2b60a.59b3.ffff8598SMTPIN_ADDED@mx.google.com> <CAFiYyc0Vnz0KXanvutXjReM1XUvaeU8obk8p+w57yU4xD4aa6w@mail.gmail.com>
Hi,
> > Why can't we replace function force_expr_to_var_cost directly with function
> > computation_cost in tree-ssa-loop-ivopt.c?
> >
> > Actually I think it is inaccurate for the current recursive algorithm in
> > force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
> > count some back-end factors and make the estimation more accurate.
> >
> > For example, using computation_cost, we may check whether back-ends can tie
> > some modes transformation expressed by SUBREG or not. If we use
> > force_expr_to_var_cost, some more computations around type
> > promotion/demotion would increase the cost estimated.
> >
> > Looking at the algorithm in force_expr_to_var_cost, it is just to analyze
> > the operator in the expression and give estimation. Should it be the same as
> > expanding EXPR to RTX and give estimation like in computation_cost?
> >
> > Any thoughts?
>
> I suppose Zdenek may remember.
computation_cost actually expands the expression to RTL. Since cost estimates
are computed a lot in ivopts, using it directly would require a huge amount of memory,
Zdenek