Rework loop statement compilation / general cleanup

[dcodeIO]

This is an attempt to tackle #1038 which yet again uncovered problems in how we compile for statements. It's still bad but we are missing the necessary infrastructure like a checker. See comments. Perfectly possible that it'll explode still - that flow stuff simply doesn't fit into my head all at once and I guess we'll need something better eventually.

[dcodeIO]

This one is interesting in that it exits the block anyway. Wondering if Binaryen could somehow optimize all of this away.

[dcodeIO]

Regarding the comment

      // TODO: For a proper CFG we'd have to take into account that the loop
      // body affects itself when executing at least twice. One way to do this
      // would be to unroll the first iteration if we detect that local states
      // differ before and after the loop executed for the first time, or we
      // can move this logic to a checker. The latter is preferrable because
      // since it can determine such a condition prior we can compile once with
      // the least common denominator of flags (i.e. null and wrap states).

another potential solution could be to recompile the body iff incompatible local states are detected, using the least common denominator. As long as all of this is encapsulated in its own flow (which we can throw away) that should be possible I guess, if only as a temporary solution. Needs some sort of diagnostics deduplication then.

[dcodeIO]

From a quick check there are just a few occasions in the code where this is relevant. To give an example, in std/util/string.ts's joinBooleanArray, we have

  var value: bool; // wrapped false
  for (let i = 0; i < lastIndex; ++i) {
    // whatever goes here assumes `value` is properly wrapped
    value = load<bool>(dataStart + i); // potentially not wrapped
  }

In this case we only load 0 or 1, so it doesn't matter, but it illustrates what can go wrong.

[dcodeIO]

Gave the recompile approach a try in the last commit, but found problems with local null states in the process. Appears that Flow#inheritConditional and friends aren't covering these properly, with the conditional variant being merely an unnecessary (and wrong) special case of #inheritMutual where left is this flow. Need to check.

[dcodeIO]

This has turned into a largish flow and loop overhaul meanwhile. In particular I'm in the process of refactoring stuff to be less smart and more correct. Will have to see how that turns out.

[dcodeIO]

Last commit contains the progress I have so far, incl.

• Refactor flow to set all flags explicitly so it never contains unnecessary flags
• Remove (most, except those I expect to become useful) unused flow flags
• Properly handle if without else where then sets nonnull
• Redo while, do and for compilation
• Diagrams and comments

Still not perfect but it's just so easy to miss something when trying to take all the possible outcomes into account, especially where branch level tree-shaking kicks in and the goal is to use as few flows as possible. Overall direction remains to be less smart but correct, even if that means that untouched output doesn't look as good as before.

[dcodeIO]

Strange one

[dcodeIO]

This is a for (let k: i8 = 0; k < 100; ++k) loop detecting that incrementing an i8 can yield an unwrapped value, hence recompiling with unified wrap states (wrapped before, not wrapped after -> not wrapped) since unaware of the k < 100 limit. As such expected, but also an optimization opportunity.

[dcodeIO]

In my initial testing I also noticed that the code example in #1038 leaked memory, but just now got around to look into that. Turned out that array literals were missing an autorelease, only affecting array literals not immediately assigned to a target, happening on

const newFaces = this.buildFaces( nextVertex, /* missing = */ [ nextFace.edge!, nextFace.edge!.next! ] 
);
// __release(missing)

but not on

const notMissing = [ nextFace.edge!, nextFace.edge!.next! ];
const newFaces = this.buildFaces( nextVertex, notMissing);
// __release(notMissing)

[dcodeIO]

There's just so much stuff that could need some modernization :)

[dcodeIO]

This is becoming somewhat unweildy, hence suggesting to merge and continue from there. Maybe some sort of general modernization PR.