[llvm-dev] byval argument causes llvm to crash after inlining

[Pan, Wei via llvm-dev]

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