[llvm] r281773 - [WebAssembly] Fix function types of CFGStackify tests

Derek Schuff via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 16 17:15:31 PDT 2016


Yeah, that sounds right. I think Alon is in the middle (beginning?) of
bringing Binaryen up to the rest of 0xc, so I'll see where he is on Monday.
Meanwhile I can do some things on the LLVM side.

On Fri, Sep 16, 2016 at 5:04 PM Dan Gohman <sunfish at mozilla.com> wrote:

> On Fri, Sep 16, 2016 at 4:41 PM, Dan Gohman <sunfish at mozilla.com> wrote:
>
>
>
> On Fri, Sep 16, 2016 at 3:04 PM, Derek Schuff <dschuff at google.com> wrote:
>
>
> Which you could simplify to
> (module
>   (func $minimal_loop (param $0 i32) (result i32)
>     (block $label$1
>       (loop $label$0
>         (br $label$0)
>       )
>     )
>   )
> )
>
> Which is a type check failure because the loop/block structure
> yields/pushes no value but the function expects an i32 return.
>
>
> This is actually a valid WebAssembly program :-). One of the main branches
> of the reference interpreter currently issues an error here, but it's a
> bug: the intention is that because the `br` makes code after it
> unreachable, so there doesn't need to be a return value after it.
>
>
> Actually, I misspoke. This is the situation where consumers are not
> required to type-check, but they may type-check, so producers have to
> follow a complex set of rules just in case. I think what we should do here
> is add type signatures to `block` and `loop`, to mirror the 0xc change, and
> then make LLVM add an `i32` return type to the `loop` and `block` here.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160917/809c1ea7/attachment.html>


More information about the llvm-commits mailing list