This is the mail archive of the
mailing list for the GCC project.
Re: [Patch for suggestions]: How do we know a loop is the peeled version?
- From: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- To: "Fang, Changpeng" <Changpeng dot Fang at amd dot com>
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>, Christian Borntraeger <borntraeger at de dot ibm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "uweigand at de dot ibm dot com" <uweigand at de dot ibm dot com>
- Date: Fri, 2 Jul 2010 20:40:30 +0200
- Subject: Re: [Patch for suggestions]: How do we know a loop is the peeled version?
- References: <D4C76825A6780047854A11E93CDE84D02F7763@SAUSEXMBP01.amd.com> <D4C76825A6780047854A11E93CDE84D02F7766@SAUSEXMBP01.amd.com>
> An additional problem is that after a loop is completely-unrolled, the loop structure
> seems not destroyed. And thus later optimization passes may still be performed
> on these non-existence loops.
if that is so, that would be a bug; but I am fairly sure that is not the case
(verify_loop_structure catches this kind of problems, and it is being run all over
the place). IIRC, complete loop unrolling only replaces the exit condition of the
loop by if (0), and the loop gets physically removed in the following cfg cleanup,