SoylentNews is people
SoylentNews
The "jump threading" compiler optimization (aka -fthread-jump) turns conditional into unconditional branches on certain paths at the expense of code size. For hardware with branch prediction, speculative execution, and prefetching, this can greatly improve performance. However, there is no scientific publication or documentation at all. The Wikipedia article is very short and incomplete.
The linked article has an illustrated treatment of common code structures and how these optimizations work.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Either I'm dead or my watch has stopped.
-- Groucho Marx's last words
(Score: 0) by Anonymous Coward on Monday November 02 2015, @02:51PM
JMP is goto. Most compilers make liberal usage of them. You just do not see it in the language.
if (x == 1) { dothis(); } else { dothat(); }
With most compilers there are at least 1 (usually 2 if you are in debug) goto statements there and a conditional one. They are hidden. You do not see them much anymore because the languages removed the need for you to type them in. In the few cases where you still need them it is still there.
Some of the early languages had poor branching and functional description so GOTO was what you did to segment things off. Things like stack management also 'hide' goto statements. Such as the x86 CALL/RET which are gotos with side effects.
The article is very similar to an idea I have kicking around. Run both ends of an if condition then toss out the results of the bad condition. You end up wasting half of your silicon power though. It also only works if there are no memory side effects for downline items. It gets worse if you nest conditional or recursively do something. Wonder how they handled that. Or if they just are breaking out the for loops. It looks like they have an interesting issue I had not considered with halting the external thread.