[PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops
Fang, Changpeng
Changpeng.Fang@amd.com
Tue Dec 21 22:45:00 GMT 2010
>For small loop bodies it might make sense to completely peel the
>prologue/epilogue loops (think of vectorizing doubles where those
>loops roll at most once). It would be nice to figure out if (or if not)
>loop analysis (or later jump threading) is able to do that.
Hi, Richard,
This is a good point. My intention is to apply the NON-ROLLING loop
Marking approach only to loops whose trip count could not be
determined at compile time. So, at the time of applying the approach,
we should first check whether the loop rolls constant time first.
Thanks,
Changpeng
>Richard.
> Thanks,
>
> Changpeng
>
>
>
> ________________________________________
> From: Zdenek Dvorak [rakdver@kam.mff.cuni.cz]
> Sent: Thursday, December 16, 2010 6:09 AM
> To: Richard Guenther
> Cc: Xinliang David Li; Fang, Changpeng; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops
>
> Hi,
>
>> Btw, any reason why we do not use static profiles for number of iteration
>> estimates? We after all _do_ use the static profile to guide the
>> maybe_hot/cold_bb tests.
>
> for loops for that we cannot determine the # of iterations statically,
> basically the only important predictors are PRED_LOOP_BRANCH and
> PRED_LOOP_EXIT, which predict that the loop will iterate about 10 times. So,
> by using static profile, we would just learn that every such loop is expected
> to iterate 10 times, which is kind of useless,
>
> Zdenek
>
More information about the Gcc-patches
mailing list