I was trying to run the simplify CFG Pass in LLVM , and delete an unreachable
basic block ("continuation" below ) after running one of my own IR
transforms , but I keep getting the
error -
While deleting: i8* %g
Use still stuck around after Def is destroyed: store i8 0, i8* %g
I am well aware of what that means, but isn't the whole purpose of the
"simplifyCFGPass" to delete the unreachable basic blocks for us ? Why
must it then throw this error ? I would assume it should simply be able to
manage all the use-def dependencies and delete the instructions in the
unreachable "continuation" basic block below.
Following is the relevant IR
entry:
%a3 = alloca i32
store i32 %a, i32* %a3
%a4 = load i32, i32* %a3
%ifcond = icmp ne i32 %a4, 0
br i1 %ifcond, label %then, label %else
then: ; preds = %entry
%gclone1 = alloca i32
store i32 0, i32* %gclone1
ret i5 0
else: ; preds = %entry
%gclone4 = alloca i64
store i64 0, i64* %gclone4
ret i5 0
continuation: ; No predecessors!
%iftmp = phi i32 [ 32, %then ], [ 64, %else ], !range !0
%datasize = alloca i32
store i32 %iftmp, i32* %datasize
%g = alloca i8 ---------------------> Issue
store i8 0, i8* %g ---------------------> Issue
ret i5 0
}
Can someone please explain why this error crops up ? Isn't the API supposed
to handle this ?
Thanks,
Malhar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170616/2f72155b/attachment.html>
On 6/16/2017 9:24 AM, Jajoo, Malhar via llvm-dev wrote:> I was trying to run the simplify CFG Pass in LLVM , and delete an > unreachable basic block ("continuation" below ) after running one of > my own IR transforms , but I keep getting the > error - > > *While deleting: i8* %g* > * > * > *Use still stuck around after Def is destroyed: store i8 0, i8* %g* > > I am well aware of what that means, but isn't the whole purpose of the > "simplifyCFGPass" to delete the unreachable basic blocks for us ? Why > must it then throw this error ? I would assume it should simply be > able to manage all the use-def dependencies and delete the > instructions in the unreachable "continuation" basic block below. > > > *Following is the relevant IR * > > entry: > %a3 = alloca i32 > store i32 %a, i32* %a3 > %a4 = load i32, i32* %a3 > %ifcond = icmp ne i32 %a4, 0 > br i1 %ifcond, label %then, label %else > then: ; preds = %entry > %gclone1 = alloca i32 > store i32 0, i32* %gclone1 > ret i5 0 > else: ; preds = %entry > %gclone4 = alloca i64 > store i64 0, i64* %gclone4 > ret i5 0 > continuation: ; No predecessors! > %iftmp = phi i32 [ 32, %then ], [ 64, %else ], !range !0 > %datasize = alloca i32 > store i32 %iftmp, i32* %datasize > %g = alloca i8---------------------> Issue > store i8 0, i8* %g ---------------------> Issue > ret i5 0 > } > > > *Can someone please explain why this error crops up ? Isn't the API > supposed to handle this ?*1. If you're going to send a testcase to llvmdev, please make sure it is complete: if it isn't possible to reproduce the issue, we're going to be left guessing what the issue is. 2. Running the verifier can catch a lot of issues (llvm::verifyModule in the C++ API). If your IR doesn't follow the rules correctly, you can get weird results. 3. It's generally a bad idea to put "alloca" instructions anywhere other than the entry block of a function, if you can avoid it; see http://llvm.org/docs/tutorial/LangImpl07.html . -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170616/dbcfdce0/attachment.html>
Hi Friedman ,
I did not put the whole IR because it would be context sensitive.
I am trying to use non-concrete types in my language but trying to
first generate the IR using dummy types and then transform the IR
to contain the correct types.
hence,I am forced to use the allocas in the middle ,
again because of the problem above that I am trying to solve.
Thanks,
Malhar
________________________________
From: Friedman, Eli <efriedma at codeaurora.org>
Sent: Friday, June 16, 2017 8:29:25 PM
To: Jajoo, Malhar; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] simplify CFG Pass in llvm
On 6/16/2017 9:24 AM, Jajoo, Malhar via llvm-dev wrote:
I was trying to run the simplify CFG Pass in LLVM , and delete an unreachable
basic block ("continuation" below ) after running one of my own IR
transforms , but I keep getting the
error -
While deleting: i8* %g
Use still stuck around after Def is destroyed: store i8 0, i8* %g
I am well aware of what that means, but isn't the whole purpose of the
"simplifyCFGPass" to delete the unreachable basic blocks for us ? Why
must it then throw this error ? I would assume it should simply be able to
manage all the use-def dependencies and delete the instructions in the
unreachable "continuation" basic block below.
Following is the relevant IR
entry:
%a3 = alloca i32
store i32 %a, i32* %a3
%a4 = load i32, i32* %a3
%ifcond = icmp ne i32 %a4, 0
br i1 %ifcond, label %then, label %else
then: ; preds = %entry
%gclone1 = alloca i32
store i32 0, i32* %gclone1
ret i5 0
else: ; preds = %entry
%gclone4 = alloca i64
store i64 0, i64* %gclone4
ret i5 0
continuation: ; No predecessors!
%iftmp = phi i32 [ 32, %then ], [ 64, %else ], !range !0
%datasize = alloca i32
store i32 %iftmp, i32* %datasize
%g = alloca i8 ---------------------> Issue
store i8 0, i8* %g ---------------------> Issue
ret i5 0
}
Can someone please explain why this error crops up ? Isn't the API supposed
to handle this ?
1. If you're going to send a testcase to llvmdev, please make sure it is
complete: if it isn't possible to reproduce the issue, we're going to be
left guessing what the issue is.
2. Running the verifier can catch a lot of issues (llvm::verifyModule in the C++
API). If your IR doesn't follow the rules correctly, you can get weird
results.
3. It's generally a bad idea to put "alloca" instructions anywhere
other than the entry block of a function, if you can avoid it; see
http://llvm.org/docs/tutorial/LangImpl07.html .
-Eli
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170619/99ff0d74/attachment.html>