> -----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? Thanks, -Jiangning > > Richard. > > > > Zdenek
