This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: loop optimization bug
- From: Jeffrey A Law <law at redhat dot com>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 01 Aug 2005 12:57:02 -0600
- Subject: Re: RFA: loop optimization bug
- References: <6ad1f91de414eb39c26b6fae1cb5cf00@apple.com> <1122399943.8352.163.camel@localhost.localdomain> <0943531f97171c3ee0b32465a6b98644@apple.com>
- Reply-to: law at redhat dot com
On Tue, 2005-07-26 at 11:06 -0700, Dale Johannesen wrote:
> No, 8 is not reachable from outside, and 7 is reachable only by falling
> into it. The "loop begin/end" indicate the RTL note locations; the
> begin
> note is actually in the middle of 7, just before the unconditional
> branch to 9.
> From the CFG point of view the loop is well formed, I think.
> Rearranging the blocks a bit makes this clearer.
Ah. It's just the actual ordering. I don't recall any code for the
tree optimizers which would force an ordering for the benefit of
the RTL optimizers.
At the least the RTL optimizers should generate correct code for
"scrambled" orderings. It may not be feasible to always optimize
such cases as well as sanely ordered code.
Just for fun you could write a pass which randomly reorders blocks
just before expansion into RTL to see what breaks :-)
jeff