RE: A question about loop ivopt

["Jiangning Liu" <jiangning dot liu at arm dot com>]

> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@gmail.com]
> Sent: Tuesday, May 22, 2012 6:36 PM
> To: Jiangning Liu
> Cc: Zdenek Dvorak; Jiangning Liu; gcc@gcc.gnu.org
> Subject: Re: A question about loop ivopt
> 
> On Tue, May 22, 2012 at 11:19 AM, Jiangning Liu <jiangning.liu@arm.com>
> wrote:
> >
> >
> >> -----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?
> 
> You are already in the middle-end and thus can use MODES_TIABLE_P
> directly.  Modes are also available on gimple variables via
> DECL/TYPE_MODE.

Richard,

But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I
would have to modify xxx-protos.h for all back-ends.

An alternative way is I define a new function hook. This way I needn't to
change all back-ends, but support several back-ends required first.

Which solution is usually preferred?

Thanks,
-Jiangning

> 
> Richard.
> 
> > Thanks,
> > -Jiangning
> >
> >>
> >> Richard.
> >>
> >>
> >> > Zdenek
> >
> >
> >
> >