llvm dev - Sep 2018 - byval argument causes llvm to crash after inlining

Hello,

With the following reduced test case, cmd "opt -always-inline t.ll"
crashes after inlining. Notice that byval argument %a will be remapped to %1
below, and consequently produces an illegal store.

%1 = alloca i32, align 4
store i32 * %1, i32 addrspace(1)** %a.addr, align 8

Looks like Inliner assumes that byval arguments are from address space 0. Or
this is just a bug in inliner?

Thanks,
Wei

t.ll:

define i32 @foo(i32 addrspace(1)* %x) {
entry:
  %y = call i32 @bar(i32 addrspace(1)* %x)
  ret i32 %y
}

define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline {
  %a.addr = alloca i32 addrspace(1)*, align 8
  store i32 addrspace(1)* %a, i32 addrspace(1)** %a.addr, align 8
  %a1 = load i32 addrspace(1)*  , i32 addrspace(1)** %a.addr, align 8
  %b = load i32, i32 addrspace(1)* %a1, align 4
  ret i32 %b
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180925/e8b368ee/attachment.html>

Well, they are from address space zero, just like all allocas and other
stack memory, right?

On Tue, Sep 25, 2018 at 1:45 PM Pan, Wei via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
>
>
> With the following reduced test case, cmd “opt -always-inline t.ll”
> crashes after inlining. Notice that byval argument %a will be remapped to
> %1 below, and consequently produces an illegal store.
>
>
>
> %1 = alloca i32, align 4
>
> store i32 * %1, i32 addrspace(1)** %a.addr, align 8
>
>
>
> Looks like Inliner assumes that byval arguments are from address space 0.
> Or this is just a bug in inliner?
>
>
>
> Thanks,
>
> Wei
>
>
>
> t.ll:
>
>
>
> define i32 @foo(i32 addrspace(1)* %x) {
>
> entry:
>
>   %y = call i32 @bar(i32 addrspace(1)* %x)
>
>   ret i32 %y
>
> }
>
>
>
> define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline {
>
>   %a.addr = alloca i32 addrspace(1)*, align 8
>
>   store i32 addrspace(1)* %a, i32 addrspace(1)** %a.addr, align 8
>
>   %a1 = load i32 addrspace(1)*  , i32 addrspace(1)** %a.addr, align 8
>
>   %b = load i32, i32 addrspace(1)* %a1, align 4
>
>   ret i32 %b
>
> }
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180925/b39b5832/attachment.html>

It is problematic when byval argument is not from address space 0.   When the
default alloca address space is 0, should we consider this IR illegal?

define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline


From: Reid Kleckner [mailto:rnk at google.com] 
Sent: Tuesday, September 25, 2018 2:38 PM
To: Pan, Wei <wei.pan at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] byval argument causes llvm to crash after inlining

Well, they are from address space zero, just like all allocas and other stack
memory, right?

On Tue, Sep 25, 2018 at 1:45 PM Pan, Wei via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
Hello,
 
With the following reduced test case, cmd “opt -always-inline t.ll” crashes
after inlining. Notice that byval argument %a will be remapped to %1 below, and
consequently produces an illegal store.
 
%1 = alloca i32, align 4
store i32 * %1, i32 addrspace(1)** %a.addr, align 8
 
Looks like Inliner assumes that byval arguments are from address space 0. Or
this is just a bug in inliner?
 
Thanks,
Wei
 
t.ll:
 
define i32 @foo(i32 addrspace(1)* %x) {
entry:
  %y = call i32 @bar(i32 addrspace(1)* %x)
  ret i32 %y
}
 
define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline {
  %a.addr = alloca i32 addrspace(1)*, align 8
  store i32 addrspace(1)* %a, i32 addrspace(1)** %a.addr, align 8
  %a1 = load i32 addrspace(1)*  , i32 addrspace(1)** %a.addr, align 8
  %b = load i32, i32 addrspace(1)* %a1, align 4
  ret i32 %b
}
 
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev