handling dead code

[binji]

@AndrewScheidecker and I were chatting yesterday about the expression value of the return statement, specifically should something like this be allowed:

...
(f32.neg (return (f32.const 1.0)))

This looks like an error to me, and sexpr-wasm-prototype and v8-native-prototype treat is an error. But it is currently allowed in ml-proto. @sunfishcode also suggested that it might be useful to allow dead code for non-optimizing wasm.

Thoughts?

[lukewagner]

Do sexpr-wasm-prototype or v8-native-prototype have the stmt=expr unification? I thought they didn't, which is why that line would be an error. However, even without stmt=expr, you run into the same question, just at statement level ((block (return) (call $foo))). Since I don't think dead code is a big problem for engines (from Odin experience) and since it doesn't add value to code generators (and, as @sunfishcode pointed out, it could be a burden) and since it's more work to specify, I'd side with not doing anything to disallow dead code.

[binji]

I guess dead code in general is probably not worth preventing, but the particular case using the value of a return still seems strange to me. For example, this fails with a type mismatch error:

(func (result i32)
  (f32.neg (return (i32.const 1))))

clearly the type of a return statement is assumed to be the type of its child expression, but that doesn't really make any sense to me.

[rossberg]

I guess dead code in general is probably not worth preventing, but the particular case using the value of a return still seems strange to me. For example, this fails with a type mismatch error:

(func (result i32)
(f32.neg (return (i32.const 1))))

clearly the type of a return statement is assumed to be the type of its child expression, but that doesn't really make any sense to me.

No, the type of a return statement is polymorphic, i.e., whatever the
surrounding expression expects. It is unrelated to its operand. The
type mismatch in your example is between the outer expression and the
function return type. This variant type-checks just fine:

(func (result i32)
  (i32.round_s/f32 (f32.neg (return (i32.const 1))))
)

As an expression, a return must be allowed to have any type. This is
to support patterns like (if (c) (return (a)) (b)), where the type
of both branches must match. The same applies to all other non-local
control-transfer constructs. That is standard behaviour in expression
languages.

I'm not sure what the issue is here. There are a million ways to write
dead code, why do we care about this one in particular?

[titzer]

On Wed, Sep 30, 2015 at 2:07 PM, rossberg-chromium <notifications@github.com

wrote:

I guess dead code in general is probably not worth preventing, but the
particular case using the value of a return still seems strange to me. For
example, this fails with a type mismatch error:

(func (result i32)
(f32.neg (return (i32.const 1))))

clearly the type of a return statement is assumed to be the type of its
child expression, but that doesn't really make any sense to me.

No, the type of a return statement is polymorphic, i.e., whatever the
surrounding expression expects. It is unrelated to its operand. The
type mismatch in your example is between the outer expression and the
function return type. This variant type-checks just fine:

(func (result i32)
(i32.round_s/f32 (f32.neg (return (i32.const 1))))
)

So the expression `if(c) (break[M] ) (break[N] )" typechecks in
call contexts where label M expects i32 and N expects f64?

As an expression, a return must be allowed to have any type. This is
to support patterns like (if (c) (return (a)) (b)), where the type
of both branches must match. The same applies to all other non-local
control-transfer constructs. That is standard behaviour in expression
languages.

I'm not sure what the issue is here. There are a million ways to write
dead code, why do we care about this one in particular?

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

[rossberg]

So the expression `if(c) (break[M] ) (break[N] )" typechecks in
call contexts where label M expects i32 and N expects f64?

Yes.

[binji]

OK, makes sense.