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