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.
