[llvm] r270478 - [LoopUnroll] Enable advanced unrolling analysis by default.

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Tue May 24 09:18:06 PDT 2016


On Mon, May 23, 2016 at 5:58 PM, Mikhail Zolotukhin
<mzolotukhin at apple.com> wrote:
>
>
> On May 23, 2016, at 4:52 PM, Mikhail Zolotukhin via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>
>
> On May 23, 2016, at 4:50 PM, Hans Wennborg <hans at chromium.org> wrote:
>
> On Mon, May 23, 2016 at 12:10 PM, Michael Zolotukhin via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>
> Author: mzolotukhin
> Date: Mon May 23 14:10:19 2016
> New Revision: 270478
>
> URL: http://llvm.org/viewvc/llvm-project?rev=270478&view=rev
> Log:
> [LoopUnroll] Enable advanced unrolling analysis by default.
>
> Summary:
> This patch turns on LoopUnrollAnalyzer by default. To mitigate compile
> time regressions, I chose very conservative thresholds for now. Later we
> can make them more aggressive, but it might require being smarter in
> which loops we're optimizing. E.g. currently the biggest issue is that
> with more agressive thresholds we unroll many cold loops, which
> increases compile time for no performance benefit (performance of those
> loops is improved, but it doesn't matter since they are cold).
>
> [..]
>
> Differential Revision: http://reviews.llvm.org/D20482
>
>
> I've reverted this in r270512, as it caused PR27847.
>
> It should be fixed in r270517. I'm going to reapply r270478 - please let me
> know if you see any failures after it.

Yes, I'm still seeing the same assert and have uploaded a new
reproducer to the bug.

I've reverted the enabling of the analysis in r270577

Thanks,
Hans


More information about the llvm-commits mailing list