https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79637
--- Comment #2 from Sebastian Pop <spop at gcc dot gnu.org> --- Here is what I see in doc/invoke.texi: @item max-fsm-thread-path-insns Maximum number of instructions to copy when duplicating blocks on a finite state automaton jump thread path. The default is 100. @item max-fsm-thread-length Maximum number of basic blocks on a finite state automaton jump thread path. The default is 10. @item max-fsm-thread-paths Maximum number of new jump thread paths to create for a finite state automaton. The default is 50. I think these parameters are quite technical. The rule is that all the magic constants should have a param instead of hard coding them in the code, so they get exposed to the users of the compiler that way. Roland, I would have liked to point you to a paper that describes the algorithm for backwards jump-threading, although we have not wrote one yet. Jeff, I think it would be good if I take the time to write that paper, and I will ask you, James, and Brian to co-sign the paper. Here is a short description of how the backwards jump-threading works: We start by looking for a switch or condition statement of the form "switch(c)". Then, following the SSA definitions backwards from "c" to its definition, until a place in the program where the condition "c" is statically known at compile time. To make the example simple, let's say we reach a statement that sets "c = 5". With that information in hand, we create a new path that starts from the basic block that sets "c = 5" and ends in the target block of the switch "case 5:". This is done by duplicating all the basic blocks on the path from "c = 5" to the target of the now known value of the condition. max-fsm-thread-length is the bound on the number of basic blocks on that path, such that we do not increase too much the code size of the program.
