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

[Derek Schuff via llvm-commits]

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/4d4c6ed5/attachment.html>