-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LICM crash, "Uses remain when a value is destroyed" #1280
Labels
bugzilla
Issues migrated from bugzilla
compile-fail
Use [accepts-invalid] and [rejects-valid] instead
loopoptim
Comments
assigned to @lattner |
Fixed. Testcase here: Patch here: Thanks! -Chris |
Verified. Thanks Chris! |
clementval
pushed a commit
to clementval/llvm-project
that referenced
this issue
Jan 17, 2022
clementval
pushed a commit
to clementval/llvm-project
that referenced
this issue
Jan 17, 2022
…t_for_1280 Add a regression test for llvm#1280
quic-asaravan
added a commit
to quic-asaravan/llvm-project
that referenced
this issue
Aug 28, 2024
This patch does 3 things: 1. Add support for optimizing the address mode of HVX load/store instructions 2. Reduce the value of Add instruction immediates by replacing with the difference from other Addi instructions that share common base: For Example, If we have the below sequence of instructions: r1 = add(r2,llvm#1024) ... r3 = add(r2,llvm#1152) ... r4 = add(r2,llvm#1280) Where the register r2 has the same reaching definition, They get modified to the below sequence: r1 = add(r2,llvm#1024) ... r3 = add(r1,llvm#128) ... r4 = add(r1,llvm#256) 3. Fixes a bug pass where the addi instructions were modified based on a predicated register definition, leading to incorrect output. Eg: INST-1: if (p0) r2 = add(r13,llvm#128) INST-2: r1 = add(r2,llvm#1024) INST-3: r3 = add(r2,llvm#1152) INST-4: r5 = add(r2,llvm#1280) In the above case, since r2's definition is predicated, we do not want to modify the uses of r2 in INST-3/INST-4 with add(r1,llvm#128/256) 4.Fixes a corner case It looks like we never check whether the offset register is actually live (not clobbered) at optimization site. Add the check whether it is live at MBB entrance. The rest should have already been verified. 5. Fixes a bad codegen For whatever reason we do transformation without checking if the value in register actually reaches the user. This is second identical fix for this pass. Co-authored-by: Anirudh Sundar <quic_sanirudh@quicinc.com> Co-authored-by: Sergei Larin <slarin@quicinc.com>
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bugzilla
Issues migrated from bugzilla
compile-fail
Use [accepts-invalid] and [rejects-valid] instead
loopoptim
Extended Description
MultiSource/Applications/oggenc picked up a failure in the nightly run. It
appears to be in the loop invariant code motion pass. Here's what happens:
$ ~/llvm/Debug/bin/opt -licm bugpoint-reduced-simplified.bc
WARNING: You're attempting to print out a bytecode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bytecode first-hand, you
can force output with the `-f' option.
While deleting: uint %tmp16.i
Use still stuck around after Def is destroyed: %exitcond155 = seteq uint 0,
%tmp16.i ; [#uses=0]
opt: Value.cpp:59: virtual llvm::Value::~Value(): Assertion `use_begin() ==
use_end() && "Uses remain when a value is destroyed!"' failed.
/home/nicholas/llvm/Debug/bin/opt((anonymous
namespace)::PrintStackTrace()+0x1a)[0x873245c]
/home/nicholas/llvm/Debug/bin/opt((anonymous
namespace)::SignalHandler(int)+0x110)[0x8732720]
[0xffffe500]
Aborted
The text was updated successfully, but these errors were encountered: