> -----Original Message----- > From: Richard Guenther [mailto:richard.guent...@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....@arm.com> > wrote: > > > > > >> -----Original Message----- > >> From: Richard Guenther [mailto:richard.guent...@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 > >> <rakd...@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 > > > > > > > >