A question about loop ivopt

[Jiangning Liu]

> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@gmail.com]
> Sent: Tuesday, May 15, 2012 10:17 PM
> To: Zdenek Dvorak
> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu
> Subject: Re: A question about loop ivopt
> 
> On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak
> <rakdver@iuuk.mff.cuni.cz> wrote:
> > 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,
> >>
> >> Do you know how huge is it? Any data on this? For GCC, is this
> "huge"
> >> memory consumption is critical enough, and there aren't any other
> else
> >> consuming even more memory?
> >
> > no, not really (I haven't worked on this for a few years now),
> although
> > of course I did some measurements when ivopts were created.  Feel
> free
> > to experiment with that, if it turned out that the memory consumption
> > and extra time spent by it is negligible, it would be a nice cleanup.
> 
> Well, I don't think we should feed arbitrary expressions to expand at
> IVOPTs time.  What probably matters most is address costs, no?
> At least that is where expand probably makes the most difference.
> So why not improve force_expr_to_var_cost instead?

OK, yes, the thing that matter most is just address cost, so I can improve
force_expr_to_var_cost.

Would it sound OK if I expose MODES_TIEABLE_P to middle-end by defining a
new target hook? I need this function to strip some operations and make the
cost estimate more accurate. If I don't expand to RTL, I would need a method
to check the modes conversion in middle end, anyway. Any idea?

Thanks,
-Jiangning

> 
> Richard.
> 
> 
> > Zdenek