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

[Fang, Changpeng]

________________________________________
From: Richard Guenther [richard.guenther@gmail.com]
Sent: Tuesday, December 14, 2010 8:35 PM
To: Zdenek Dvorak
Cc: Fang, Changpeng; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops

On Tue, Dec 14, 2010 at 10:05 PM, 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)

Thanks,

Changpeng





>Richard.