[wasm] Binary 11: AST changes.

[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
LOG=Y

Committed: https://crrev.com/2aa4656eebc863332146f5c864e341f55972b85b
Cr-Commit-Position: refs/heads/master@{#35896}

[bradnelson, 2016-03-23 19:14:26]

lgtm

Given the size of this diff, I'd hate to belabor the review.
Hope this can land soon.
Thanks for turning up all the asm.js issues!

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.cc
File src/wasm/asm-wasm-builder.cc (right):

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:604: if (target_var == nullptr && target_prop ==
nullptr) {
You return above, why guard this, as you return in each of the above?

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:673: if (target_var == nullptr && target_prop ==
nullptr) {
Add returns instead of guard here?

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:825: // TODO(titzer): handle overflow here.
Spec allows 0 - 2^32 -1 here. What did you mean?

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:987: uint16_t tmp_y =
current_function_builder_->AddLocal(kAstI32);
Did we want to turn these into asm specific opcodes (mozilla does FWIW)?
(not in this change)

I had started down that direction, but found that TF Calls seem to turn into
separate invocations if you reference them in multiple branches in some cases.
Is there a correct way to express a call + multiple uses of the return value in
the TF graph without loading/storing to the stack?

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:1379: current_function_builder_->Emit(kExprEnd);
return here vs the break down below, might be more obvious. (optional)

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
File test/mjsunit/wasm/asm-wasm-f64.js (right):

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
test/mjsunit/wasm/asm-wasm-f64.js:281: // TODO(bradnelson) f64_cos,
Some several of these are implemented in fdlibm in the snapshot with
approximations that don't match what you get if you hit the full versions. For
those, an exact match may not be possible (unless we want to call out to js for
cos/sin/exp ?)

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
File test/mjsunit/wasm/asm-wasm-literals.js (right):

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
test/mjsunit/wasm/asm-wasm-literals.js:91: return {f0: f0, f1: f1, f4: f4, f64:
f64, f127: f127, f128: f128, f256: f256, f1000: f1000, f2000000, fmax: fmax};
wrap?

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
test/mjsunit/wasm/asm-wasm-literals.js:132: return; // TODO(bradnelson):
unsigned literals are broken!
Have a fix, but might wait until this lands.

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
File test/mjsunit/wasm/asm-wasm-u32.js (right):

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
test/mjsunit/wasm/asm-wasm-u32.js:46: return +((a >>> 0) + (b >>> 0));
Ah, clever, had been proposing something more roundabout to check these, before
seeing this.

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm.js
File test/mjsunit/wasm/asm-wasm.js (right):

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm....
test/mjsunit/wasm/asm-wasm.js:27: function PosIntLiteralTest() {
Can we wrap this in a closure like the ones at the bottom? (since it has a 'var
module')

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm....
test/mjsunit/wasm/asm-wasm.js:38: return {f0: f0, f1: f1, f4: f4, f64: f64,
f128: f128, f256: f256, f1000: f1000, f2000000, fmax: fmax};
wrap

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm....
test/mjsunit/wasm/asm-wasm.js:1105: print("Testing foreign variables...");
You mean to leave this in?

[titzer, 2016-03-23 19:53:06]

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.cc
File src/wasm/asm-wasm-builder.cc (right):

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:604: if (target_var == nullptr && target_prop ==
nullptr) {
On 2016/03/23 19:14:25, bradnelson wrote:
> You return above, why guard this, as you return in each of the above?

Because paranoia :-)

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:673: if (target_var == nullptr && target_prop ==
nullptr) {
On 2016/03/23 19:14:25, bradnelson wrote:
> Add returns instead of guard here?

Don't want to silently forget to generate code.

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:825: // TODO(titzer): handle overflow here.
On 2016/03/23 19:14:25, bradnelson wrote:
> Spec allows 0 - 2^32 -1 here. What did you mean?

Right. If it is 2^31, e.g., and then we multiply by {size}, that will overflow.

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:987: uint16_t tmp_y =
current_function_builder_->AddLocal(kAstI32);
On 2016/03/23 19:14:25, bradnelson wrote:
> Did we want to turn these into asm specific opcodes (mozilla does FWIW)?
> (not in this change)
> 
> I had started down that direction, but found that TF Calls seem to turn into
> separate invocations if you reference them in multiple branches in some cases.
> Is there a correct way to express a call + multiple uses of the return value
in
> the TF graph without loading/storing to the stack?

It's probably about the same amount of work either way.

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
File test/mjsunit/wasm/asm-wasm-literals.js (right):

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
test/mjsunit/wasm/asm-wasm-literals.js:91: return {f0: f0, f1: f1, f4: f4, f64:
f64, f127: f127, f128: f128, f256: f256, f1000: f1000, f2000000, fmax: fmax};
On 2016/03/23 19:14:25, bradnelson wrote:
> wrap?

I'll split these tests out into a different CL and do it there.

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm-...
test/mjsunit/wasm/asm-wasm-literals.js:132: return; // TODO(bradnelson):
unsigned literals are broken!
On 2016/03/23 19:14:25, bradnelson wrote:
> Have a fix, but might wait until this lands.

Acknowledged.

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm.js
File test/mjsunit/wasm/asm-wasm.js (right):

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm....
test/mjsunit/wasm/asm-wasm.js:27: function PosIntLiteralTest() {
On 2016/03/23 19:14:25, bradnelson wrote:
> Can we wrap this in a closure like the ones at the bottom? (since it has a
'var
> module')

I ended up moving this all together into a different file.

https://codereview.chromium.org/1830663002/diff/1/test/mjsunit/wasm/asm-wasm....
test/mjsunit/wasm/asm-wasm.js:1105: print("Testing foreign variables...");
On 2016/03/23 19:14:25, bradnelson wrote:
> You mean to leave this in?

I crashed here a couple times and it was useful to find out where I was in the
test.

[bradn, 2016-03-23 19:58:49]

bradnelson@google.com changed reviewers:
+ bradnelson@google.com

[bradn, 2016-03-23 19:58:50]

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.cc
File src/wasm/asm-wasm-builder.cc (right):

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:604: if (target_var == nullptr && target_prop ==
nullptr) {
On 2016/03/23 19:53:05, titzer wrote:
> On 2016/03/23 19:14:25, bradnelson wrote:
> > You return above, why guard this, as you return in each of the above?
> 
> Because paranoia :-)

Seems like leaving the UNREACHABLE unguarded would be more paranoid?

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:825: // TODO(titzer): handle overflow here.
On 2016/03/23 19:53:05, titzer wrote:
> On 2016/03/23 19:14:25, bradnelson wrote:
> > Spec allows 0 - 2^32 -1 here. What did you mean?
> 
> Right. If it is 2^31, e.g., and then we multiply by {size}, that will
overflow.

Ah, yes.

https://codereview.chromium.org/1830663002/diff/1/src/wasm/asm-wasm-builder.c...
src/wasm/asm-wasm-builder.cc:987: uint16_t tmp_y =
current_function_builder_->AddLocal(kAstI32);
On 2016/03/23 19:53:05, titzer wrote:
> On 2016/03/23 19:14:25, bradnelson wrote:
> > Did we want to turn these into asm specific opcodes (mozilla does FWIW)?
> > (not in this change)
> > 
> > I had started down that direction, but found that TF Calls seem to turn into
> > separate invocations if you reference them in multiple branches in some
cases.
> > Is there a correct way to express a call + multiple uses of the return value
> in
> > the TF graph without loading/storing to the stack?
> 
> It's probably about the same amount of work either way.

K, although I still want to understand why tf call node results can't be reused,
but that's orthogonal to this review.

[dougc, 2016-03-24 01:18:20]

On 2016/03/23 18:16:10, titzer wrote:

It does not appear to take into account the discussion and issues raised in
https://github.com/WebAssembly/design/pull/611 ?

1. DoReturn() is popping multiple 'values' from the stack, but it is an AST node
stack not a values stack so should only be popping one return node which might
represent multiple values. The idea of it being a values stack was shown to be
invalid near the top of the discussion. This patch seems to use kAstStm to
represent a zero values AST node and this node would need popping even if the
function returned zero values?

2. It does not appear to address the significant validation issue you
acknowledged at the end of this discussion. 'Ah ha! Thanks for your example. No
we don't actually detect that case. Have to think about that.'?

3. The above are very fundamental design matters, and until addressed and the
validation sound then it hardly seems possible to make any claims about it being
'more efficient'. It might be a small matter to check the stack depths, but
could this be done and the efficiency re-tested?

4. This issue description claims a 'space' advantage. If this refers to the
encoding size then some immediate operator counts are removed but they are
replaced by extra opcode markers so it seems relatively even? If it refers to
the productions stack then this is removed but the AST node stack might be
larger now, but neither are likely a significant space burden?

[titzer, 2016-03-24 09:20:47]

On 2016/03/24 01:18:20, dougc wrote:
> On 2016/03/23 18:16:10, titzer wrote:
> 
> It does not appear to take into account the discussion and issues raised in
> https://github.com/WebAssembly/design/pull/611 ?
> 
> 1. DoReturn() is popping multiple 'values' from the stack, but it is an AST
node
> stack not a values stack so should only be popping one return node which might
> represent multiple values. The idea of it being a values stack was shown to be
> invalid near the top of the discussion. This patch seems to use kAstStm to
> represent a zero values AST node and this node would need popping even if the
> function returned zero values?
> 
> 2. It does not appear to address the significant validation issue you
> acknowledged at the end of this discussion. 'Ah ha! Thanks for your example.
No
> we don't actually detect that case. Have to think about that.'?
> 

Yeah the solution to that is to keep track of the stack height at the beginning
of the block and when popping from the stack, only allow popping up to the block
begin boundary. I didn't implement this yet but that's how the prototype
rossberg@ was working on for the spec works (though it uses recursion for
blocks).

> 3. The above are very fundamental design matters, and until addressed and the
> validation sound then it hardly seems possible to make any claims about it
being
> 'more efficient'. It might be a small matter to check the stack depths, but
> could this be done and the efficiency re-tested?
> 
> 4. This issue description claims a 'space' advantage. If this refers to the
> encoding size then some immediate operator counts are removed but they are
> replaced by extra opcode markers so it seems relatively even? If it refers to
> the productions stack then this is removed but the AST node stack might be
> larger now, but neither are likely a significant space burden?

No, the space savings is in the decoder data structures. The previous decoder
needed intermediate data structures to track the production stack (the Tree*)
nodes. That's not necessary anymore.

[dougc, 2016-03-24 11:09:24]

On 2016/03/24 09:20:47, titzer wrote:
> > 2. It does not appear to address the significant validation issue you
> > acknowledged at the end of this discussion. 'Ah ha! Thanks for your example.
> No
> > we don't actually detect that case. Have to think about that.'?
> > 
> 
> Yeah the solution to that is to keep track of the stack height at the
beginning
> of the block and when popping from the stack, only allow popping up to the
block
> begin boundary. I didn't implement this yet but that's how the prototype
> rossberg@ was working on for the spec works (though it uses recursion for
> blocks).

Yes, that would seem to resolve that issue, thanks. Might it be a small matter
to add that check to this patch, perhaps it could be done in 'Value Pop()' by
checking against the stack_depth in the Control struct at the top of the
control_ stack? It's also not clear how this could work for the kExprElse block
in this patch as it does not seem to push a new control block, or does it?

> > 4. This issue description claims a 'space' advantage. If this refers to the
> > encoding size then some immediate operator counts are removed but they are
> > replaced by extra opcode markers so it seems relatively even? If it refers
to
> > the productions stack then this is removed but the AST node stack might be
> > larger now, but neither are likely a significant space burden?
> 
> No, the space savings is in the decoder data structures. The previous decoder
> needed intermediate data structures to track the production stack (the Tree*)
> nodes. That's not necessary anymore.

Might there be a tradeoff here too. Save on the production stack data structure
which might have been an issue for deep expression trees, but now the AST node
stack can be very deep for broad blocks.

[titzer, 2016-03-29 13:30:14]

On 2016/03/24 11:09:24, dougc wrote:
> On 2016/03/24 09:20:47, titzer wrote:
> > > 2. It does not appear to address the significant validation issue you
> > > acknowledged at the end of this discussion. 'Ah ha! Thanks for your
example.
> > No
> > > we don't actually detect that case. Have to think about that.'?
> > > 
> > 
> > Yeah the solution to that is to keep track of the stack height at the
> beginning
> > of the block and when popping from the stack, only allow popping up to the
> block
> > begin boundary. I didn't implement this yet but that's how the prototype
> > rossberg@ was working on for the spec works (though it uses recursion for
> > blocks).
> 
> Yes, that would seem to resolve that issue, thanks. Might it be a small matter
> to add that check to this patch, perhaps it could be done in 'Value Pop()' by
> checking against the stack_depth in the Control struct at the top of the
> control_ stack? It's also not clear how this could work for the kExprElse
block
> in this patch as it does not seem to push a new control block, or does it?
> 

This was what I was planning to do, yes.

> > > 4. This issue description claims a 'space' advantage. If this refers to
the
> > > encoding size then some immediate operator counts are removed but they are
> > > replaced by extra opcode markers so it seems relatively even? If it refers
> to
> > > the productions stack then this is removed but the AST node stack might be
> > > larger now, but neither are likely a significant space burden?
> > 
> > No, the space savings is in the decoder data structures. The previous
decoder
> > needed intermediate data structures to track the production stack (the
Tree*)
> > nodes. That's not necessary anymore.
> 
> Might there be a tradeoff here too. Save on the production stack data
structure
> which might have been an issue for deep expression trees, but now the AST node
> stack can be very deep for broad blocks.

It's strictly better, since the Tree* data structure is larger than the elements
on the AST node stack, and the AST node stack recycles space, while Tree* did
not.

[binji, 2016-03-29 18:04:34]

https://codereview.chromium.org/1830663002/diff/60001/src/wasm/wasm-macro-gen.h
File src/wasm/wasm-macro-gen.h (right):

https://codereview.chromium.org/1830663002/diff/60001/src/wasm/wasm-macro-gen...
src/wasm/wasm-macro-gen.h:67: #define WASM_SELECT(cond, tval, fval) cond, tval,
fval, kExprSelect
this should be tval, fval, cond, kExprSelect
(the previous code was wrong too)

https://codereview.chromium.org/1830663002/diff/60001/test/mjsunit/wasm/wasm-...
File test/mjsunit/wasm/wasm-constants.js (right):

https://codereview.chromium.org/1830663002/diff/60001/test/mjsunit/wasm/wasm-...
test/mjsunit/wasm/wasm-constants.js:98: var kExprNext = 0x16;
update to match wasm-opcodes.h

[titzer, 2016-03-30 08:37:24]

https://codereview.chromium.org/1830663002/diff/60001/src/wasm/wasm-macro-gen.h
File src/wasm/wasm-macro-gen.h (right):

https://codereview.chromium.org/1830663002/diff/60001/src/wasm/wasm-macro-gen...
src/wasm/wasm-macro-gen.h:67: #define WASM_SELECT(cond, tval, fval) cond, tval,
fval, kExprSelect
On 2016/03/29 18:04:34, binji wrote:
> this should be tval, fval, cond, kExprSelect
> (the previous code was wrong too)

Good catch. Names were wrong, order was right.

https://codereview.chromium.org/1830663002/diff/60001/test/mjsunit/wasm/wasm-...
File test/mjsunit/wasm/wasm-constants.js (right):

https://codereview.chromium.org/1830663002/diff/60001/test/mjsunit/wasm/wasm-...
test/mjsunit/wasm/wasm-constants.js:98: var kExprNext = 0x16;
On 2016/03/29 18:04:34, binji wrote:
> update to match wasm-opcodes.h

Done.

[bradn, 2016-04-05 18:32:14]

bradnelson@google.com changed reviewers:
+ aseemgarg@chromium.org

[titzer, 2016-04-21 12:06:59]

Description was changed from

==========
[wasm] Reimagine WASM as a postorder binary format.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

to

==========
[wasm] Binary 11: Reimagine WASM as a postorder binary format.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

[titzer, 2016-04-22 13:41:08]

Description was changed from

==========
[wasm] Binary 11: Reimagine WASM as a postorder binary format.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

to

==========
[wasm] Binary 11: WASM is now a postorder binary format.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

[titzer, 2016-04-28 11:51:23]

Description was changed from

==========
[wasm] Binary 11: WASM is now a postorder binary format.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

to

==========
[wasm] Binary 11: WASM is now a postorder binary format.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

[titzer, 2016-04-28 11:51:51]

Description was changed from

==========
[wasm] Binary 11: WASM is now a postorder binary format.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

to

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

[titzer, 2016-04-29 08:48:56]

The CQ bit was checked by titzer@chromium.org

[titzer, 2016-04-29 08:48:57]

The patchset sent to the CQ was uploaded after l-g-t-m from
bradnelson@chromium.org
Link to the patchset: https://codereview.chromium.org/1830663002/#ps360001
(title: " ")

[titzer, 2016-04-29 08:49:01]

The CQ bit was unchecked by titzer@chromium.org

[commit-bot: I haz the power, 2016-04-29 08:49:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1830663002/360001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1830663002/360001

[titzer, 2016-04-29 08:49:06]

The CQ bit was unchecked by titzer@chromium.org

[titzer, 2016-04-29 08:50:09]

Description was changed from

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
==========

to

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
==========

[titzer, 2016-04-29 08:50:16]

The CQ bit was checked by titzer@chromium.org

[commit-bot: I haz the power, 2016-04-29 08:50:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1830663002/360001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1830663002/360001

[titzer, 2016-04-29 08:52:38]

Description was changed from

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
==========

to

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
LOG=Y
==========

[titzer, 2016-04-29 08:54:36]

The CQ bit was unchecked by titzer@chromium.org

[titzer, 2016-04-29 08:54:44]

The CQ bit was checked by titzer@chromium.org

[commit-bot: I haz the power, 2016-04-29 08:54:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1830663002/360001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1830663002/360001

[commit-bot: I haz the power, 2016-04-29 09:15:30]

Description was changed from

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
LOG=Y
==========

to

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
LOG=Y
==========

[commit-bot: I haz the power, 2016-04-29 09:15:31]

Committed patchset #19 (id:360001)

[commit-bot: I haz the power, 2016-05-01 22:03:27]

Description was changed from

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
LOG=Y
==========

to

==========
[wasm] Binary 11: WASM AST is now postorder.
[wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
LOG=Y

Committed: https://crrev.com/2aa4656eebc863332146f5c864e341f55972b85b
Cr-Commit-Position: refs/heads/master@{#35896}
==========

[commit-bot: I haz the power, 2016-05-01 22:03:29]

Patchset 19 (id:??) landed as
https://crrev.com/2aa4656eebc863332146f5c864e341f55972b85b
Cr-Commit-Position: refs/heads/master@{#35896}