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.

Sign up for GitHub

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

Jump to bottom

malloc not eliminated, even though result is only used in a null check #1685

Closed
llvmbot opened this issue Apr 6, 2007 · 4 comments
Closed

malloc not eliminated, even though result is only used in a null check #1685

llvmbot opened this issue Apr 6, 2007 · 4 comments
Assignees
@lattner
Labels
bugzilla Issues migrated from bugzilla code-quality

Comments

@llvmbot
Copy link
Member

llvmbot commented Apr 6, 2007

Bugzilla Link 1313
Resolution FIXED
Resolved on Feb 22, 2010 12:49
Version 1.0
OS Linux
Attachments reduced testcase
Reporter LLVM Bugzilla Contributor

Extended Description

From the reduced example:

    %tmp15.i.i.i23 = malloc [2564 x i32]
    icmp eq [2564 x i32]* %tmp15.i.i.i23, null
    %retval = zext i1 %0 to i32
    ret i32 %retval

Believe it or not, this came up in a real program!
I see no reason why the optimizers should not assume
that the malloc was successful, eliminate the call
and have the function return 0.
@llvmbot
Copy link
Member Author

llvmbot commented Apr 6, 2007

assigned to @lattner

@lattner
Copy link
Collaborator

lattner commented Apr 6, 2007

Implemented, testcase here: Transforms/InstCombine/malloc2.ll

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

-Chris

@llvmbot
Copy link
Member Author

llvmbot commented Apr 6, 2007

You probably don't want to do this unconditionally. On MacOSX, for example, a failing malloc call sets
errno, which might be checked elsewhere. Various versions of malloc also exist that have side effects
such as accumulating statistics or emitting a log message.

@lattner
Copy link
Collaborator

lattner commented Apr 6, 2007

I agree that there are use cases that can be affected. For example, on a 32-bit system, it is reasonable to
assume that "if (malloc(~0U))" will fail. However, that's depending on undefined behavior (e.g. the call
could succeed on a 64-bit machine), so I think we're ok.

-Chris

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
llvm#1685 3053-sched010~014のlit移行
117036b
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lattner lattner

Labels
bugzilla Issues migrated from bugzilla code-quality
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lattner @llvmbot