On 05/12/14 14:14, David Malcolm wrote:
You asked me to speak up if my factoring turned up a case where the
existing code might be broken - and I'm slightly nervous about the last
change above.
AIUI, the invariants that hold here are that we're walking the
singly-linked list of the (struct nb_iter_bound *) of a loop, and have a
loop exit - and the existing code assumed that the nb_iter_bound's stmt
is a GIMPLE_COND.
Could that ever not be the case; could we ever be dealing with another
kind of statement?
As I understand it, the "is_exit" field is set by "record_estimate",
which is called by "estimate_numbers_of_iterations_loop" on each element
of get_loop_exit_edges (loop).
Is it possible for, say, a suitably-constructed function full of gotos
and a switch to fool the loop-handling code into considering a switch
statement as an exit from a loop? (e.g. after optimizing a goto inside a
case, maybe?).
Then again, the existing code calls gimple_cond_make_true/make_false on
the stmt, so implicitly requires it to be a GIMPLE_COND.
Sorry for my ignorance here; I'm less familiar with the loop-analysis
code.
Maybe. This is code I haven't had to ever really look at -- it may well
be broken in this regard.
jeff
