RE: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops

["Fang, Changpeng" <Changpeng dot Fang at amd dot com>]

Hi, 
>hmmm.... I forgot about this.  OK, I withdraw my objection against the patch, although
>I would suggest the following changes:
>-- rename BB_PRE_POST_LOOP_HEADER to something like BB_HEADER_OF_NONROLLING_LOOP,

Thanks. I will do this.

>-- in estimate_numbers_of_iterations_loop, for loops with this flags use
 >  record_niter_bound (loop, double_int_two, true, false)
 >  to make tree-level loop optimizations know that the loop does not roll,
>-- the check for the flag in loop_prefetch_arrays should not be needed, then.
>Zdenek

I have a new idea about this. How about, "if the flag is ON, we consider the loop as "optimize for size"")?
In this way, we will consider the loop as a cold area and turn off related optimizations on it.

Thanks,

Changpeng 


________________________________________
From: Zdenek Dvorak [rakdver@kam.mff.cuni.cz]
Sent: Wednesday, December 15, 2010 3:22 AM
To: Xinliang David Li
Cc: Fang, Changpeng; Richard Guenther; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops

Hi,

> >>>  >why not simply change the profile updating to correctly indicate that these loops do not roll?
> >>> >That way, all the optimizations would profit, not just those aware of the new bb flag,
> >>>
> >>> Maybe my understanding is not correct. But I feel not comfortable using profile of trip count
> >>> to guard loop optimizations.
> >>
> >> it is already used that way; i.e., you do not need to change anything in the optimizations, just
> >> make sure that the edge probabilities are sensible.
> >>
> >>> For a given program, different data sizes will result in quite different
> >>> loop trip counts.
> >>
> >> That should not be the case -- for the pre/post loops generated in vectorization, we know the
> >> expected # of iterations, based on their purpose; e.g., for loops inserted so that the # of iterarations
> >> is divisible by 4, we know that the loop will iterate at most three times (and probably less), etc.
> >>
> >>> By the way, what optimizations else do you think will benefit from disabling for small trip count
> >>> loops, significantly?
> >>
> >> Anything where we check whether we should optimize for speed or code size,
> >
> >>I agree with Zdenek (without having looked at the patch sofar).
> >
> > I think my patch (adding a bb flag) provides a simple and yet effective solution for the unnecessay
> > code expansion problem in prefetching, unswitching, and loop unrolling. However, I don't mind
> > updating the profile information for the same purpose.
> >
> > Now, suppose we know a loop will roll at most 3 times at runtime. How should we update the profile
> > information to let the expected_loop_iterations to know this value? ( I got lost here about the
> > edge probabilities issues)
> >
>
>
> In general, without FDO, gcc does not estimate loop iteration
> according to the back-edge probability computed by static prediction
> (predict.c).  This is less than ideal. For instance, when
> builtin_expect is used to annotate the loop bound, the information
> will be lost.

hmmm.... I forgot about this.  OK, I withdraw my objection against the patch, although
I would suggest the following changes:
-- rename BB_PRE_POST_LOOP_HEADER to something like BB_HEADER_OF_NONROLLING_LOOP,
-- in estimate_numbers_of_iterations_loop, for loops with this flags use
   record_niter_bound (loop, double_int_two, true, false)
   to make tree-level loop optimizations know that the loop does not roll,
-- the check for the flag in loop_prefetch_arrays should not be needed, then.

Zdenek