This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?

Richard.


> Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]