Eliminate `continue` statement

[rossberg]

In a language with break-from-block, the continue statement is redundant. Any loop of the form

l: while (C) { ... continue l; ... }

can equivalently be rewritten to

l: while (C) l2: { ... break l2; ... }

While a separate continue statement is useful in user-facing syntax, I see no benefit in having it in Wasm. In particular, since labels are implicit, so there isn't even any encoding overhead in the second form.

I propose removing continue.

[kg]

Labels are implicit? That's interesting, when did we decide on that? If that's the case, I agree that continue x is redundant and unnecessary.

[rossberg]

At least that was my understanding wrt to the binary encoding. It's what the V8 prototype does -- break and continue just take a relative depth parameter.

[sunfishcode]

This does look like it's an improvement over the current design. It slightly obscures backedges in the case of forever loops, but makes do_while control flow simpler, which is nice.

That said, I also have an open proposal for a much broader redesign of the control constructs in #299.

[titzer]

I'm not sure we're gaining anything by reducing the number of control flow
constructs here. On the one hand we're adding more forms of comparisons,
more conversions, and more integer doodads, and then we're taking away
common control flow patterns. This is not serving producers well, and it is
not really making implementations any simpler, since the surface area of
all those other operations completely dwarfs implementing control flow.

No one even has a completely functional pipeline and we're changing
fundamentals with zero data based on taste.

On Mon, Aug 24, 2015 at 8:23 PM, Dan Gohman notifications@github.com
wrote:

This does look like it's an improvement over the current design. It
slightly obscures backedges in the case of forever loops, but makes
do_while control flow simpler, which is nice.

That said, I also have an open proposal for a much broader redesign of the
control constructs in #299
#299.

—
Reply to this email directly or view it on GitHub
#310 (comment).

[kg]

Would it help if I put a wasm backend in my personal compiler so we have a test corpus to play with until LLVM is ready?

[titzer]

On Mon, Aug 24, 2015 at 9:05 PM, Katelyn Gadd notifications@github.com
wrote:

Would it help if I put a wasm backend in my personal compiler so we have a
test corpus to play with until LLVM is ready?

Yeah, let's see what comes out :-)

—
Reply to this email directly or view it on GitHub
#310 (comment).

[rossberg]

@titzer, this is not taking away any pattern. A producer just literally replaces continue n with break n-1, that's all.

[titzer]

No, they need to have another block inside the loop order to do so.

On Mon, Aug 24, 2015 at 9:40 PM, rossberg-chromium <notifications@github.com

wrote:

@titzer https://github.com/titzer, this is not taking away any pattern.
A producer just literally replaces continue n with break n-1, that's all.

—
Reply to this email directly or view it on GitHub
#310 (comment).

[rossberg]

@titzer, in asm.js break can exit any statement, not just blocks or loops. But even if Wasm is supposed to be more restricted (should it?), isn't that a triviality?

[titzer]

In v8-native, a loop is just like a block in that it contains multiple
statements/expressions. IIUC you are proposing that loop has only a single
statement/expression and that to encode continue you make a loop with a
block as its subexpression and then break the subblock, correct?

If so, I think that's a lot of aggravation for no gain anywhere.

On Mon, Aug 24, 2015 at 10:14 PM, rossberg-chromium <
notifications@github.com> wrote:

@titzer https://github.com/titzer, in asm.js break can exit any
statement, not just blocks or loops. But even if Wasm is supposed to be
more restricted (should it?), isn't that a triviality?

—
Reply to this email directly or view it on GitHub
#310 (comment).

[rossberg]

I see. I hadn't noticed that about v8-native. The AST semantics doesn't say anything to the contrary, so I have been assuming the obvious C statement structure so far. Has this actually been discussed?

[AndrewScheidecker]

I think the primary benefit to eliminating the continue operation is that it simplifies the AST context; e.g. the context to mimic the JavaScript break and continue semantics as the binary encoding from the polyfill prototype requires is annoying. Another way to simplify the context (and eliminate continue) without requiring extra label nodes is to give loop nodes two branch targets: one for break, and one for continue.

e.g. this WebAssembly: (loop $break $continue ... (branch $continue) ... (branch $break) ...)
could translate to this JavaScript: a: while(true) { ... continue a; ... break a; ... }
and can also be easily translated to lower level branching operations.

Incidentally, I also think the text format should eventually require referencing labels, locals, and globals by name; that would mean only consumers of the binary format need to understand indexing. With rules like loops introducing two labels, or separate index spaces for locals by type, that's potentially a lot of complexity that could be isolated to the binary format. It makes sense to keep the indexing in the text format for prototyping, but once the reference interpreter also implements a binary format, it would be nice to get rid of it.

[kg]

Another way to simplify the context (and eliminate continue) without requiring extra label nodes is to give loop nodes two branch targets: one for break, and one for continue.

This would address my concerns. I like it.

Incidentally, I also think the text format should eventually require referencing labels, locals, and globals by name; that would mean only consumers of the binary format need to understand indexing.

That would be great, since I basically don't understand how the numeric indexes work right now despite trying to :-)