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 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.

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


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