Detect loops & improved value tracking

[NaC-L]

Basically we can find loops if the jump is calculated in the edge between jump and jump location. However, as we currently propagate the values, some of the information is lost. So when calculating constants, we should also come up with a way to locate where the constant was calculated. As far as I know, constants are obtained with getOrCreateConstant, so they are not unique. Additionally, when we determine that we are in a loop, we can lift in "loop mode" without folding and with phi's. After we lift the loop, we should try to find loop invariant code, unroll certain variables and etc.

[gkgoat1]

Basically we can find loops if the jump is calculated in the edge between jump and jump location. However, as we currently propagate the values, some of the information is lost. So when calculating constants, we should also come up with a way to locate where the constant was calculated. As far as I know, constants are obtained with getOrCreateConstant, so they are not unique. Additionally, when we determine that we are in a loop, we can lift in "loop mode" without folding and with phi's. After we lift the loop, we should try to find loop invariant code, unroll certain variables and etc.

Loop detection could also be done by detecting reentry of a specific code segment: the same x86 code and instruction pointer alongsides identical (if applicable) control flow flattening states and virtualized program counters and instruction encryption keys; once detected, we can loop back to the original block and inject phis. We can then make our optimizations work with phis.

[NaC-L]

Partial progress landed via the Themida-frontier sequence:

• PR lifter: generalized-loop control-field/slot phi infrastructure for Themida frontier #112 adds activeGeneralizedLoopControlFieldState and the retrieve_generalized_loop_* family. When the lifter detects a generalized loop, it can now emit a two-incoming phi of canonical + backedge values for control-slot / control-field / target-slot / phi-address loads at the loop header, instead of folding each branch to a single concrete value. That corresponds roughly to the "lift in loop mode with phi's" part of the description here.
• PR lifter: preserve integer cast widths in computePossibleValues #111 teaches computePossibleValues to preserve integer cast widths, which matters specifically for the rolled post-loop arithmetic chains this issue mentions.
• PR lifter: skip raw zero in solvePath multi-target switch enumeration #110 stops solvePath's multi-target switch emission from cross-producting raw zero into a bogus imageBase case, which used to pollute loop-target enumeration.

Loop detection (the first sentence of the OP) and loop-invariant code / unrolling (the last sentence) are still not systematically addressed — the current behavior is triggered by specific generalized-loop backup states rather than a general loop-detection pass. Leaving this issue open as the broader tracker.