[PATCH] [analyzer] Refactor conditional expression evaluating code

[Pavel Labath]

  This got me thinking a bit... For a moment there I wasn't sure why is
  the thing still working. :)
  Then I realized that LiveVariables has a default code which marks
  (non-recursive) subexpressions as live

  Currently the whole idea is to compute all the subexpressions once,
  when visiting the full expression and then just store them so that
  they are available when I go through the branches the second time.
  E.g., for an expression like (a && b) && A() the produced cfg looks
  like:

                  a             <- value for "a" computed here
              a && ...       <- first terminator, uses the value of "a"
                 / \
                /   b           <- value for "b" computed here
               | (a&&b)&&...    <- second terminator, uses the value of "b"
               |    / \
               |   /  A()       <- value for A() computed here
               \  /   /
                \/   /
           (a && b) && A()      <- value for (a && b) and the full
  expression computed here
           (a && b) && ...       <- third terminator, which tests
  whether to run the destructor
                / \                        it uses the value of (a && b)
  computed above.
               |   |                        since (a&&b) is a child of
  the full expression it is marked
               |   \                       as live, and it will not get
  reaped even if something
               |  ~A()                   happens to be between this line
  and the one above.
               \  /
               ....            <- execution continues normally

  Note that in the terminators I do not re-evaluate the conditions - I
  merely lookup the values in the state and use them. For the first two
  cases, I use the existing code, which finds the correct values using
  the (a and b, respectively) logic in ResolveCondtion(). In the third
  case, this logic fails (that's why we got the assertion failures) and
  that's why I introduced an additional case which goes "if the value is
  already present in the state, just use that, and don't resolve
  anything".

  While writing this, I got the idea that I could reconstruct the
  expression value from the leaves also in the terminators (perhaps
  that's what you thought I wanted to do?). This way I could even get
  rid of the strange logic in ResolveCondition and just replace it by a
  call to evaluateLogicalExpression. Shall I try that approach?

  PS: I have a feeling this would go a lot faster if we discuss it more
  interactively. Shall we try to schedule a short meeting about this?

http://llvm-reviews.chandlerc.com/D1340