[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