[Bug middle-end/39284] Computed gotos combined too aggressively

["timo.kreuzer at reactos dot org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284

Timo Kreuzer <timo.kreuzer at reactos dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timo.kreuzer at reactos dot org

--- Comment #12 from Timo Kreuzer <timo.kreuzer at reactos dot org> ---
Any updates on this (after 5 years)? Or any workarounds?

I tried to do some optimization to my x86 instruction parser code by using
computed gotos. This post
(https://blogs.oracle.com/nike/entry/fast_interpreter_using_gcc_s) suggests
that it should give good speed improvements and the shown compilation results
looked promising.
But the results with newer GCC versions were so bad, I went back to a simple
switch()

The 2 major speed improvements (less instructions / improved branch prediction)
are completely killed by this bug.
Another thing, that I find suspicious (maybe this is some crazy optimization I
just don't understand) is that GCC doesn't generate a single JMP with a memory
operand anymore, but first loads the memory into a register and then does a
register based JMP, even when the load operation is exactly the same in all
cases.

>From the comments it looks like there is already a working patch. Why is it not
committed? I'd really appreaciate if you could fix this asap.

PS: It would be great if you could make this work for switch statements in a
loop as well! Normally people don't hassle with computed gotos, they use a
switch. If this is in a loop and cases go back directly to the switch
statement, the additional jump should be eliminated, possibly duplicating n
instructions from the top of the loop before the switch.