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

Unused malloc/free don't get optimized #1573

Closed
llvmbot opened this issue Feb 15, 2007 · 2 comments
Closed

Unused malloc/free don't get optimized #1573

llvmbot opened this issue Feb 15, 2007 · 2 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla code-quality

Comments

@llvmbot
Copy link
Member

llvmbot commented Feb 15, 2007

Bugzilla Link 1201
Resolution FIXED
Resolved on Feb 22, 2010 12:43
Version 1.9
OS All
Reporter LLVM Bugzilla Contributor
CC @nlewycky

Extended Description

The optimizer doesn't remove malloc/free instructions when the allocated memory
is not used.

My example (but it does the same with simply a couple of malloc/free instructions)

Before optimization:

int %main(int %argc, ubyte** %argv)
{
%c_19 = alloca ubyte*
%malloc_206 = malloc ubyte, uint 10
store ubyte* %malloc_206, ubyte** %c_19
%tmp_207 = load ubyte** %c_19
free ubyte* %tmp_207

ret int 0
}

After optimization:

int %main(int %argc, ubyte** %argv) {
%malloc_206 = malloc [10 x ubyte]
%malloc_206.sub = getelementptr [10 x ubyte]* %malloc_206, int 0, int 0
free ubyte* %malloc_206.sub
ret int 0
}

@llvmbot
Copy link
Member Author

llvmbot commented Feb 15, 2007

assigned to @lattner

@lattner
Copy link
Collaborator

lattner commented Apr 14, 2007

Implemented, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047494.html

Testcase here:
test/Transforms/InstCombine/malloc-free-delete.ll

-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 Apr 11, 2022

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
* This fixes a number of issues.

When dealing with values (including aggregates) that have dependent type,
FIR requires that we thread the type parameter values through the IR.
Note that boxed values contain type parameters inside the box. It is a
requirement that the type parameter(s) can be recovered from a box
value.

  - Add verifiers that determine if an Op requires type parameters or
    not and checks that the correct number of parameters is specified.
  - Fix lowering to add the proper number of type parameters.
  - Fix transformations that were losing type parameter information.

Fix code gen bug that was scaling the size of an element twice.

Fix tests to reflect these changes.

* Rework the code that is meant to recover the type parameters from a
boxed value. We cannot handle derived types with LEN parameters at all.
Boxed values are immutable, of course, so recovering data from them
should not be controversial.

Boxed variables need to be reconsidered. It may be possible currently to
have a variable of type box that is in a logical inconsistent state, so
it would be incorrect to read its state directly. Simplifying this
should be considered.

Also:
  - refactor redundant type tests to use the SPOT tests from FIRType.h
  - replace the term "length parameter" with "LEN parameter" to be
    consistent and to follow the Fortran surface syntax, which uses LEN.
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GlobalISel bug fixes from trunk
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 code-quality
Projects
None yet
Development

No branches or pull requests

2 participants