Skip to content
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

Closed
nlewycky opened this issue Sep 12, 2006 · 3 comments
Closed

LICM crash, "Uses remain when a value is destroyed" #1280

nlewycky opened this issue Sep 12, 2006 · 3 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead loopoptim

Comments

@nlewycky
Copy link
Contributor

Bugzilla Link 908
Resolution FIXED
Resolved on Nov 07, 2018 00:17
Version trunk
OS All
Attachments simplified testcase

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

@nlewycky
Copy link
Contributor Author

assigned to @lattner

@lattner
Copy link
Collaborator

lattner commented Sep 12, 2006

Fixed.  Testcase here: 
Transforms/LICM/2006-09-12-DeadUserOfSunkInstr.ll

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060911/037730.html

Thanks!

-Chris

@nlewycky
Copy link
Contributor Author

Verified. Thanks Chris!

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
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

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…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
Projects
None yet
Development

No branches or pull requests

2 participants