This is in reply to the posting below.
I am not a compiler writer type, so I am probably in over my head a bit.
Several years ago I was a bit interested in something called code slicers.
An example of one (probably no longer supported) is UNRAVEL
(Information Technology Laboratory | NIST )
Their basic idea is to identify the algorithm which serves to determine the
value of variable at a specific location in the code.
That is they seek to determine all the paths which influence a computation
result. They do not make any assumptions about the possible paths which lead
to the specific location. (ergo many such paths)
They accomplish this by walking the computation backwards and pruning out
stuff which is just not relevant (you unfortunately cannot prune out the
stuff which is not relevant)
You appear to have the very same problem (except the Boolean evaluation
which serves to indicate a need for backtracking), with a minor twist. You
have instrumentation which allows you to determine the path.
The strategy which they use (and the problems which they experience) are
likely to be the same problems as you will experience
This is what I see
(1) There will be functions which cannot be inverted. Identifying them is
the principle task. They are the locations where in addition to control
information, data checks are necessary
(2) In the instrumented code you know the locations where the results have
to be reversed. You can infer the location in the actual code. Construct the
paths based not on the instrumented code, but the actual code
(3) There are probably only a finite number of paths, each identified by a
different instrumentation configuration (ie a state variable). You reverse
the erroneous result by running a pre-compiled procedure generated from the
(4) Associate the reversing algorithm with the state and execute when