Optimize compilation of switch statements for untagged variants

[cristianoc]

First step: remove the distinction between cases with and without payload in the toplevel algorithm.

On this test:

@unboxed
type rec t =
  | Boolean(bool)
  | @as(null) Null
  | String(string)
  | Number(float)
  | Object(Dict.t<t>)
  | Array(array<t>)

type group = {
  id: string,
  name: string,
}

let decodeGroup = group => {
  switch group {
  | (dict{"id": String(id), "name": String(name)}) =>
  (id, name)
  | _ => ("e", "f")
  }
}

Before:

function decodeGroup(group) {
  let match = group.id;
  if (match === undefined) {
    return [
      "e",
      "f"
    ];
  }
  if (match === null) {
    return [
      "e",
      "f"
    ];
  }
  if (typeof match !== "string") {
    return [
      "e",
      "f"
    ];
  }
  let match$1 = group.name;
  if (match$1 !== undefined && !(match$1 === null || typeof match$1 !== "string")) {
    return [
      match,
      match$1
    ];
  } else {
    return [
      "e",
      "f"
    ];
  }
}

After:

function decodeGroup(group) {
  let match = group.id;
  if (match === undefined) {
    return [
      "e",
      "f"
    ];
  }
  if (typeof match !== "string") {
    return [
      "e",
      "f"
    ];
  }
  let match$1 = group.name;
  if (match$1 !== undefined && typeof match$1 === "string") {
    return [
      match,
      match$1
    ];
  } else {
    return [
      "e",
      "f"
    ];
  }
}

The 3 cases have become 2: check for optional fields and check for which case it is.

[cristianoc]

There's the question of whether the check for optional fields could also be incorporated at the pattern matching level.
Can't remember where that happens -- need to take a look.
An alternative is to do a back-end optimisation post-generation, though that would need to check that the two instances of return ["e", "f"]; in the different conditionals are both the same code, and either without side effects, or produce equivalent side effect (returning), which might not be trivial.

[cometkim]

An alternative is to do a back-end optimisation post-generation, though that would need to check that the two instances of return ["e", "f"]; in the different conditionals are both the same code, and either without side effects, or produce equivalent side effect (returning), which might not be trivial.

Yes, it wouldn't be trivial and often inefficient at runtime. The simplest way to reduce computation and run safely with side effects is to create a function with a captured return, but I'm not sure if it's optimizable.

Or we can ignore it as this kind of repetition is very well compressed in the real world via HTTP Content-Encoding

[cometkim]

Umm, with side effects it compiles to

function decodeGroup(group) {
  let match = group.id;
  if (match !== undefined) {
    if (typeof match === "string") {
      let match$1 = group.name;
      if (match$1 !== undefined) {
        if (typeof match$1 === "string") {
          return [
            match,
            match$1
          ];
        }
        console.log("aaaaaaaa");
        return [
          "e",
          "f"
        ];
      }
      console.log("aaaaaaaa");
      return [
        "e",
        "f"
      ];
    }
    console.log("aaaaaaaa");
    return [
      "e",
      "f"
    ];
  }
  console.log("aaaaaaaa");
  return [
    "e",
    "f"
  ];
}

(Makes bit better to understand the flow without optimization)

Compiler obviously emits unnecessary branches. It should be:

function decodeGroup(group) {
  let match = group.id;
  if (match !== undefined) {
    if (typeof match === "string") {
      let match$1 = group.name;
      if (match$1 !== undefined) {
        if (typeof match$1 === "string") {
          return [
            match,
            match$1
          ];
        }
      }
    }
  }
  console.log("aaaaaaaa");
  return [
    "e",
    "f"
  ];
}

(undefined checks also can be removed)

[cristianoc]

Optional fields: #7143

[cristianoc]

After rebasing on master, it's close to optimal for the motivating example.
Need to explore more this approach, then make it work (it breaks on lots of examples).

let decodeGroup = group => {
  switch group {
  | (dict{"id": String(id), "name": String(name)}) =>
  (id, name)
  | _ => ("e", "f")
  }
}

compiles to:

function decodeGroup(group) {
  let id = group.id;
  if (typeof id !== "string") {
    return [
      "e",
      "f"
    ];
  }
  let name = group.name;
  if (typeof name === "string") {
    return [
      id,
      name
    ];
  } else {
    return [
      "e",
      "f"
    ];
  }
}

[cristianoc]

This is a decompilation of the lambda code even before getting to the pattern matching compilation later on in the back-end:

let decodeGroup = fun group ->
  try
    let id = group.id in
    let match_val = group.dictValuesType in
    
    match id with
    | 1 -> 
        (match group.name with
         | 1 -> (id, group.name)
         | _ -> raise Exit)
    | _ -> raise Exit
  with Exit ->
    (0, ("e", "f"))

It means that the presence of String(id) changes the compilation, even if for the purpose of code generation it could be treated as if it were just id.

[cristianoc]

This is a decompilation of the lambda code even before getting to the pattern matching compilation later on in the back-end:

let decodeGroup = fun group ->
  try
    let id = group.id in
    let match_val = group.dictValuesType in
    
    match id with
    | 1 -> 
        (match group.name with
         | 1 -> (id, group.name)
         | _ -> raise Exit)
    | _ -> raise Exit
  with Exit ->
    (0, ("e", "f"))

It means that the presence of String(id) changes the compilation, even if for the purpose of code generation it could be treated as if it were just id.

There's something deep in the very first phases of pattern matching algorithm where pairs of values cannot be a single case.
That is true for pairs, as is e.g. for records with 2 fields.
It would be pretty hard to change that, so this code can be considered optimal given reasonable constraints.

[cristianoc]

@zth this is ready for a functional review.
Then the code can be cleaned up a bit, but the functionality stays.

[zth]

Tagging @cknitt as well.

[cristianoc]

This illustrates why the optimisation is not safe on tagged variants: #7146

[cknitt]

Will test against a real-world project.

[cristianoc]

Will test against a real-world project.

Great! I was going to ask.

[cknitt]

Tested against a real-world project, and the output looked very good! 👍

Compared to alpha.4:

• Actually not that many changes
• Only correct changes
• Concrete examples of nice improvements:
  • if x { return true; } else { return false } gone
  • for React refs created with React.useRef(Nullable.null), does not unnecessarily check for undefined anymore

[zth]

Agreed, looks great in my tests as well! 👍

[cristianoc]

This can be further simplified as a simple simplification, in a separate PR.

[zth]

Theoretically this could be simplified to == null || type of "boolean", but I'm not sure it's that important tbh.