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

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


We could maybe work around this after/during cfg-stackification by looking
for block/loop fallthrough-returns and fabricating some value to make it
typecheck. Could this also happen with an infinite loop inside some other
construct?

On Fri, Sep 16, 2016 at 3:04 PM Derek Schuff <dschuff at google.com> wrote:

> Hm, didn't realize that it was valid. Although I put that workaround in my
> local git the other day and just today realized that there are other C
> tests that result in the same kind of IR, so yes, I was probably about to
> discover that :)
>
> Anyway yes, if you have:
>
> target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
> target triple = "wasm32-unknown-unknown"
>
> define i32 @minimal_loop(i32* %p) {
> entry:
>   store volatile i32 0, i32* %p
>   br label %loop
> loop:
>   store volatile i32 1, i32* %p
>   br label %loop
> }
>
> You get:
>
> .text
> .file "infloop.ll"
> .globl minimal_loop
> .type minimal_loop, at function
> minimal_loop:                           # @minimal_loop
> .param   i32
> .result i32
> # BB#0:                                 # %entry
> i32.const $push0=, 0
> i32.store $drop=, 0($0), $pop0
> .LBB0_1:                                # %loop
>                                         # =>This Inner Loop Header: Depth=1
> loop                            # label0:
> i32.const $push1=, 1
> i32.store $drop=, 0($0), $pop1
> br       0               # 0: up to label0
> .LBB0_2:
> end_loop                        # label1:
> .endfunc
> .Lfunc_end0:
> .size minimal_loop, .Lfunc_end0-minimal_loop
>
> which is the following (bearing in mind Binaryen's current
> almost-but-not-quite-0xc state):
>
> (module
>   (memory 1)
>   (export "memory" (memory $0))
>   (export "minimal_loop" (func $minimal_loop))
>   (func $minimal_loop (param $0 i32) (result i32)
>     (drop
>       (i32.store
>         (get_local $0)
>         (i32.const 0)
>       )
>     )
>     (block $label$1
>       (loop $label$0
>         (drop
>           (i32.store
>             (get_local $0)
>             (i32.const 1)
>           )
>         )
>         (br $label$0)
>       )
>     )
>   )
> )
>
> 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.
>
>
>
> On Fri, Sep 16, 2016 at 2:38 PM Dan Gohman <sunfish at mozilla.com> wrote:
>
> On Fri, Sep 16, 2016 at 1:58 PM, Derek Schuff via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> Author: dschuff
> Date: Fri Sep 16 15:58:31 2016
> New Revision: 281773
>
> URL: http://llvm.org/viewvc/llvm-project?rev=281773&view=rev
> Log:
> [WebAssembly] Fix function types of CFGStackify tests
>
> Make the function's declared type match its (lack of) return type
>
> Modified:
>     llvm/trunk/test/CodeGen/WebAssembly/cfg-stackify.ll
>
> Modified: llvm/trunk/test/CodeGen/WebAssembly/cfg-stackify.ll
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/WebAssembly/cfg-stackify.ll?rev=281773&r1=281772&r2=281773&view=diff
>
> ==============================================================================
> --- llvm/trunk/test/CodeGen/WebAssembly/cfg-stackify.ll (original)
> +++ llvm/trunk/test/CodeGen/WebAssembly/cfg-stackify.ll Fri Sep 16
> 15:58:31 2016
> @@ -284,7 +284,7 @@ entry:
>  ; OPT: i32.store $drop=, 0($0), $pop{{[0-9]+}}{{$}}
>  ; OPT: br 0{{$}}
>  ; OPT: .LBB7_2:
> -define i32 @minimal_loop(i32* %p) {
> +define void @minimal_loop(i32* %p) {
>
>
> The previous code with a non-void return type and an infinite loop instead
> of a return is valid in LLVM IR, so the backend should be able to handle
> it. Was this code triggering a bug?
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160916/c1d224b7/attachment.html>


More information about the llvm-commits mailing list