Fixed point based solver infrastructure?

[modulovalue]

I noticed the following section in flow_analysis.dart:

  ...
  /// Note that a more accurate analysis would be to iterate to a fixed point,
  /// and only remove promotions if it can be shown that they aren't restored
  /// later in the loop body.  If we switch to a fixed point analysis, we should
  /// be able to remove this method.
  FlowModel conservativeJoin(
    FlowModelHelper helper,
    Iterable<int> writtenVariables,
    Iterable<int> capturedVariables,
  ) {
  ...

I was a little surprised that we don't already use a fixed point solver and I have a few questions regarding that:

• I'd like to understand the constraints around which the conservativeJoin approach was chosen. I suppose it was a pragmatic choice to keep things simpler so introducing the machinery for a full fixed point solver would not be needed?
• Does the team still see it as desirable to eventually move toward a fixed point based solver?
• I know it's hard to tell without actually working out all the details, but do we know of any challenges that prevent us from moving to a fixed point based solver approach other than someone actually investing the time to do it?

I'm asking because I'd like to investigate that direction further and I wanted to align with the team. I'm working on a general purpose dataflow solver framework over type-resolved-Dart and I'm wondering if that same approach (minus type annotations/identifier resolution) could also be adopted to earlier stages.