This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/15242] pessimization of "goto *"
- From: "zlomj9am at artax dot karlin dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Jul 2004 08:42:27 -0000
- Subject: [Bug rtl-optimization/15242] pessimization of "goto *"
- References: <20040501142654.15242.anton@mips.complang.tuwien.ac.at>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From zlomj9am at artax dot karlin dot mff dot cuni dot cz 2004-07-16 08:42 -------
Subject: Re: pessimization of "goto *"
> > Adding an new flag is possible. However, I do not see why you explicitelly want
> > to disable reorder-blocks.
>
> We need it for the dynamic superinstruction optimization (aka
> selective inlining, PLDI'98 p. 291) in Gforth and further
> optimizations building on that (other people working on efficient
> interpreters/dynamic code generators have the same problem; e.g., I
> recently talked to Etienne Gagnon (http://sablevm.org/) about this;
> qemu also uses -fno-reorder-blocks).
>
> For dynamic superinstructions we need to ensure that the machine code
> corresponding to source code between two labels is between the
> addresses that gcc produces for the labels. The flag
> -fno-reorder-blocks almost gives us that (but the sharing of the
> "goto *"s breaks that).
I see.
> Even for just plain interpreters (without dynamic superinstructions),
> the sharing of the "goto *"s resulting from the merging of code after
> conditional jumps (as shown in the simplified testcase) will often
> reduce performance significantly through lower BTB accuracy. So for
> performance one probably wants to use -fno-reorder-blocks there,
> unless this results in merging the "goto *"s, as it does now.
I see. So duplication of computed jumps probably should be at -O
and have a special flag too.
Josef
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242