1986863 - wasm-gc: ScalarReplacement.cpp: experiment with more aggressive escape analysis

Status: NEW

(Core :: JavaScript Engine: JIT, enhancement, P3)

Description

[Julian Seward [:jseward]]

In ScalarReplacement.cpp, function IsWasmStructEscaped uses a modest analysis
("This is a cheap and conservative escape analysis"). In practice it fails to
transform some obvious cases, eg (in pseudo-MIR):

  if (..) {
     objT = struct.new(args)
  } else {
     objE = struct.new(other args)
  }
  obj = phi(objT, objE)
  .. use obj in some non-escaping way ..

and

   objInner = struct.new(args)
   objOuter = struct.new(other args, including objInner)
   // objInner never mentioned again
   ..
   use objOuter in some non-escaping way

(in which case objOuter is SRA'd but objInner isn't).

It would be interesting to:

(1) Decouple the escape analysis from the actual SRA transformation. So that
we first do an escape analysis of the whole function, to compute a set of
non-escaping MIR struct.new allocation nodes.

(2) Work through the set of nodes and do the actual SRA transformation.

That would make it easy to experiment with different analyses, since that would
just mean replacing (1).

In particular I have in mind a backwards "escapeness-propagating" pass, in
which we first mark all [relevant] MIR nodes as non-escaping, and then
propagate escapeness backwards, from node outputs to inputs, and iterate to a
fixed point in the usual way. I believe this would demonstrate that all of
objT, objE, objInner and objOuter in the examples above are
non-escaping.

Comment 1

[Nicolas B. Pierron [:nbp]]

One note relative to the first example:

(In reply to Julian Seward [:jseward] from comment #0)

  if (..) {
     objT = struct.new(args)
  } else {
     objE = struct.new(other args)
  }
  obj = phi(objT, objE)
  .. use obj in some non-escaping way ..

This would require some changes in scalar replacement to handle multiple "entry" by potentially calling initStartingState on multiple locations.

The fact that Scalar Replacement does not remove allocation instruction and only abstract the memory of the allocation, should already work in our favor for decoupling our Escape Analysis, as our Scalar Replacement passes could be unordered.