@inline and deterministic results

[lexaknyazev]

Usually, the compiler makes its own assessment whether a function should be inlined at call-sites. However one could force it with an @inline decoration.

For some reason, adding the decoration to already-to-be-inlined functions sometimes lead to surprisingly different compilation output with two notable variations:

1. Increased number of local variables at call-site (although the callee is inlined anyway).
2. Inverted loop conditions, i.e., for (let i: u32 = 0; i < c; i++) the compiler puts the variables in reverse order and emits i32.gt_u.

Although these variations are quite minor, they sometimes decrease runtime performance and make debugging more difficult.

[MaxGraey]

I guess that's because inlining in binaryen comes with local optimizations usually ("inlining-optimization" pass). While inline on frontend side is always inline without local optimizations

[lexaknyazev]

Specifically, changing this:

namespace Bar {
    export function getFoo() : u32 {
        return load<u32>(CONST_LOCATION, 20);
    }
}

to this:

namespace Bar {
    @inline export function getFoo() : u32 {
        return load<u32>(CONST_LOCATION, 20);
    }
}

is enough to cause a regression in my case.

[dcodeIO]

Background here is that when the @inline decorator is present, the AssemblyScript compiler immediately inlines the function (potentially doing better than when doing so after the fact), no questions asked. If it is not present, Binaryen decides during optimization, based on optimization options, whether and where it makes sense to inline a function. So the difference manifests (only) when optimizing the module, with pass order affecting heuristics.

To give a concrete example, when AS knows that it is inlining a function, it can omit some amount of small integer wrapping, shadow stack setup, etc. which would otherwise need to be inserted defensively.

[lexaknyazev]

potentially doing better than when doing so after the fact

That was my initial expectation. However in some cases binaryen's inline pass manages to produce a better output.

[MaxGraey]

Btw could you make minimal repro? I can't reproduce deterministic behaviour with your samples:
playground

I am sure it is present, I would just like to understand under what conditions it occurs

[lexaknyazev]

Here's the smallest example I could get.

Config ("converge": true is required to repro):

{
  "targets": {
    "release": {
      "optimizeLevel": 3,
      "shrinkLevel": 3,
      "converge": true,
      "noAssert": true
    }
  }
}

Source:

@inline function loadZ() : u32 {
  return load<u32>(16);
}

@inline function loadX(a: i32, b: i32): u32 {
  return load<u32>(2 * a + b);
}

export function baz(v: u32): void {
  if (v) unreachable();
}

export function foo(v0: i32, v1: i32, v2: i32): u32 {
  const x = loadX(v0, 0);
  const y = loadX(v0, 1);
  const z = loadZ();

  baz(z + x + y);

  struct.v0 = v0;
  struct.v1 = v1;
  struct.v2 = v2;

  return z;
}

@unmanaged class Struct {
  v0: u32;
  v1: u32;
  v2: u32;
}
const struct = changetype<Struct>(0);

With the very first @inline present (on loadZ), the foo() function has four local variables. Without it, only three.

[MaxGraey]

So foo function (with @inline):

(func $module/foo (param $0 i32) (param $1 i32) (param $2 i32) (result i32)
  (local $3 i32)
  local.get $0
  i32.const 1
  i32.shl
  local.tee $3
  i32.load offset=1
  local.get $3
  i32.load
  i32.const 16
  i32.load
  local.tee $3
  i32.add
  i32.add
  if
   unreachable
  end
  i32.const 0
  local.get $0
  i32.store
  i32.const 4
  local.get $1
  i32.store
  i32.const 8
  local.get $2
  i32.store
  local.get $3
 )

foo without @inline for loadX and loadZ:

(func $module/foo (param $0 i32) (param $1 i32) (param $2 i32) (result i32)
  (local $3 i32)
  (local $4 i32)
  local.get $0
  i32.const 1
  i32.shl
  local.tee $3
  i32.load
  local.set $4
  local.get $3
  i32.load offset=1
  i32.const 16
  i32.load
  local.tee $3
  local.get $4
  i32.add
  i32.add
  if
   unreachable
  end
  i32.const 0
  local.get $0
  i32.store
  i32.const 4
  local.get $1
  i32.store
  i32.const 8
  local.get $2
  i32.store
  local.get $3
 )

diff (with / without @inlines):

(func $module/foo (param $0 i32) (param $1 i32) (param $2 i32) (result i32)
  (local $3 i32)
+ (local $4 i32)
  local.get $0
  i32.const 1
  i32.shl
  local.tee $3
+ i32.load
+ local.set $4
+ local.get $3
  i32.load offset=1
- local.get $3
- i32.load
  i32.const 16
  i32.load
  local.tee $3
+ local.get $4
  i32.add
  i32.add
  if
   unreachable
  end
  i32.const 0
  local.get $0
  i32.store
  i32.const 4
  local.get $1
  i32.store
  i32.const 8
  local.get $2
  i32.store
  local.get $3
 )

[MaxGraey]

this could be fixed by adding early inline pass #2117