This is the mail archive of the gcc-patches@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: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops


One more thing about FDO -- using average trip count can be misleading
too -- however if loop multi-version according to trip count value
profiling (currently missing), it will be more precise.

David

On Wed, Dec 15, 2010 at 1:22 AM, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> 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
>


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