Bug 50482 - optimizer malloc

Project Infrastructure LLVM Dev List Archives
1

Hi,
This is my first post and I am looking at the bug 50482 . It is related to malloc optimization. I have a doubt related to malloc optimization.
Here is the code:-

#include <stdlib.h>
int test() {
  char *x = malloc(-1);
  char *y = malloc(2);
  int ret = (x != NULL) && (y != NULL);
  free(x); free(y);
  return ret;
}

Above program returns 1. 

During optimization (-O1) when llvm IR goes through instruction combining pass then program behaves incorrect. 

This link follows Instruction combining pass. 

[https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2639](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2639) 

Where it is mentioned that 

If we have a malloc call which is only used in any amount of comparisons to 
null and free calls, delete the calls and replace the comparisons with true 
or false as appropriate.

but is it feasible solution to replace every malloc call with true or false when comparison to null and free calls?

Thank you,

Bhumitram Kumar
2

Hi Bhumitram Kumar,

First, great you are interested in working on LLVM.

I think you might have stumbled on a bug report that is not great for beginners.

I don't think there is a bug here, optimizing this to return 1 seems fine. That
said, the people reporting the bug obviously disagree which will at least cause
some discussion before any decision on how to deal with this is made. Long story
short, you might want to look at another bug.

All the best,
Johannes

3

What exactly is being optimized here? Does program performance improve?

4

Consider a program that allocates memory, computes something in it and
frees the memory. If the computation can be done at compile time and all
stores are removed by Dead Store Elimination and the address doesn't
otherwise leak, the program can be reduced to malloc + free (or
new+delete). That makes it very beneficial to be able to remove the
allocation pair as well.

Joerg

5

isn't that something clang does already very good?

see clang/gcc comparison: 58483 – missing optimization opportunity for const std::vector compared to std::array

clang removed the new/deletes completely around the compile time calculation

6

But in this case, we are not removing a malloc/free pair that does not leak
information because the side effect determines the return value.