This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/8092] [3.3/3.4 regression] cross-jump triggers too often
- From: "bernd dot paysan at gmx dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Dec 2003 20:43:42 -0000
- Subject: [Bug optimization/8092] [3.3/3.4 regression] cross-jump triggers too often
- References: <20020930012601.8092.bernd.paysan@gmx.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From bernd dot paysan at gmx dot de 2003-12-27 20:43 -------
Subject: Re: [3.3/3.4 regression] cross-jump triggers too often
Hi rth at redhat dot com,
On Saturday 27 December 2003 06:02, you wrote:
> ------- Additional Comments From rth at redhat dot com 2003-12-27 05:02
> ------- Subject: Re: [3.3/3.4 regression] cross-jump triggers too often
>
> On Fri, Dec 26, 2003 at 09:11:55PM -0000, bernd dot paysan at gmx dot de
wrote:
> > A central dispatcher is *bad*, because the branch predictor can not make
> > up any correlation between jump location and jump target.
>
> No, this causes unacceptable compile-time problems. Did you not
> see the bits in bb-reorder that undo this? Are they not working
> for some reason?
They are not working when you do -fno-reorder-blocks, since that skips the
phase completely. This is the current status of the problem here:
-fno-crossjumping and -fno-reorder-blocks together leaves the central
dispatcher in place.
BTW: The cleanup stuff in bb-reorder.c is after the instruction combining
stuff, so the computed goto doesn't get combined with previous instructions,
though it could be combined. Example: You want to jump through a pointer,
goto **pointer. This ends up (on x86) as
mov (%reg1),%reg2
jmp %reg2
instead of doing
jmp (%reg1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8092