thr3ads.net - llvm dev - [LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing? [Apr 2015]

If this information is useful, please help other people find it:
Share via:

Jiangning Liu

2015-Apr-01 02:59 UTC

[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

Hi Mats,

I think Kevin's point is malloc can return 0, if malloc/free pair is
optimized way, the semantic of the original would be changed.

On the other hand, malloc/free are special functions, but programmers can
still define their own versions by not linking std library, so we must
assume malloc/free always have side-effect like other common functions,
unless we know we will link std library only at link-time.

Thanks,
-Jiangning


2015-03-31 17:51 GMT+08:00 Kevin Qin <kevinqindev at gmail.com>:
> Yes, I classified `new (std::nothrow)` to be a malloc like allocation. See
> the next sentence.
>
>
> 2015-03-31 17:48 GMT+08:00 mats petersson <mats at
planetcatfish.com>:
>
>> > I think we can do such optimization with operator new, because new
>> never returns null.
>>
>> This is incorrect in the case of `new (std::nothrow) ...` - the whole
>> point of `(std::nothrow)` is to tell new that it should return NULL in
>> case of failure, rather than throw an exception (bad_alloc).
>>
>> But the point here is not the actual return value, but the fact that
>> the compiler misses that the constructor has side-effects.
>>
>> --
>> Mats
>>
>>
>>
>> On 31 March 2015 at 10:44, mats petersson <mats at
planetcatfish.com> wrote:
>> > The optimisation here is that "nothing uses `m`, so we can
assume
>> > allocation works and remove the malloc + free pair".
>> >
>> > What is the purpose of allocating 1 (or 100, or 1000000000) bytes,
>> > never use it, and then free it immediately?
>> >
>> > The test-code in the bug report does rely on the constructor being
>> > called, and the bug here is probably [as I'm not familiar with
the
>> > workings of the compiler in enough detail] that it doesn't
recognize
>> > that the constructor has side-effects.
>> >
>> > --
>> > Mats
>> >
>> > On 31 March 2015 at 10:24, Kevin Qin <kevinqindev at
gmail.com> wrote:
>> >> Hi,
>> >>
>> >>
>> >> When looking into the bug in
>> https://llvm.org/bugs/show_bug.cgi?id=21421, I
>> >> found a regression test in
Transforms/InstCombine/malloc-free-delete.ll
>> >> against me to directly fix it. The test is,
>> >>
>> >> define i1 @foo() {
>> >> ; CHECK-LABEL: @foo(
>> >> ; CHECK-NEXT: ret i1 false
>> >>   %m = call i8* @malloc(i32 1)
>> >>   %z = icmp eq i8* %m, null
>> >>   call void @free(i8* %m)
>> >>   ret i1 %z
>> >> }
>> >>
>> >> According to
http://www.cplusplus.com/reference/cstdlib/malloc/,
>> malloc may
>> >> return null if this memory allocation fails. So why we assume
malloc()
>> >> always returns a non-null pointer here?
>> >>
>> >> I think we can do such optimization with operator new, because
new
>> never
>> >> returns null. But for all malloc like allocation(malloc,
calloc, and
>> new
>> >> with std::nothrow), we shouldn't do this.
>> >>
>> >> That regression test exists for a long time, I'm not sure
if there's
>> any
>> >> special reason. Does anybody know about this?
>> >>
>> >> --
>> >> Thanks,
>> >>
>> >> Kevin Qin
>> >>
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >>
>>
>
>
>
> --
> Best Regards,
>
> Kevin Qin
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150401/77a143bd/attachment.html>

David Majnemer

2015-Apr-01 04:52 UTC

head link

[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

On Tue, Mar 31, 2015 at 7:59 PM, Jiangning Liu <liujiangning1 at
gmail.com>
wrote:
> Hi Mats,
>
> I think Kevin's point is malloc can return 0, if malloc/free pair is
> optimized way, the semantic of the original would be changed.
>
> On the other hand, malloc/free are special functions, but programmers can
> still define their own versions by not linking std library, so we must
> assume malloc/free always have side-effect like other common functions,
> unless we know we will link std library only at link-time.
>
If programmers want to do this, they need to compile their program with
-ffreestanding.

>
> Thanks,
> -Jiangning
>
>
> 2015-03-31 17:51 GMT+08:00 Kevin Qin <kevinqindev at gmail.com>:
>
>> Yes, I classified `new (std::nothrow)` to be a malloc like allocation.
>> See the next sentence.
>>
>>
>> 2015-03-31 17:48 GMT+08:00 mats petersson <mats at
planetcatfish.com>:
>>
>>> > I think we can do such optimization with operator new, because
new
>>> never returns null.
>>>
>>> This is incorrect in the case of `new (std::nothrow) ...` - the
whole
>>> point of `(std::nothrow)` is to tell new that it should return NULL
in
>>> case of failure, rather than throw an exception (bad_alloc).
>>>
>>> But the point here is not the actual return value, but the fact
that
>>> the compiler misses that the constructor has side-effects.
>>>
>>> --
>>> Mats
>>>
>>>
>>>
>>> On 31 March 2015 at 10:44, mats petersson <mats at
planetcatfish.com>
>>> wrote:
>>> > The optimisation here is that "nothing uses `m`, so we
can assume
>>> > allocation works and remove the malloc + free pair".
>>> >
>>> > What is the purpose of allocating 1 (or 100, or 1000000000)
bytes,
>>> > never use it, and then free it immediately?
>>> >
>>> > The test-code in the bug report does rely on the constructor
being
>>> > called, and the bug here is probably [as I'm not familiar
with the
>>> > workings of the compiler in enough detail] that it doesn't
recognize
>>> > that the constructor has side-effects.
>>> >
>>> > --
>>> > Mats
>>> >
>>> > On 31 March 2015 at 10:24, Kevin Qin <kevinqindev at
gmail.com> wrote:
>>> >> Hi,
>>> >>
>>> >>
>>> >> When looking into the bug in
>>> https://llvm.org/bugs/show_bug.cgi?id=21421, I
>>> >> found a regression test in
>>> Transforms/InstCombine/malloc-free-delete.ll
>>> >> against me to directly fix it. The test is,
>>> >>
>>> >> define i1 @foo() {
>>> >> ; CHECK-LABEL: @foo(
>>> >> ; CHECK-NEXT: ret i1 false
>>> >>   %m = call i8* @malloc(i32 1)
>>> >>   %z = icmp eq i8* %m, null
>>> >>   call void @free(i8* %m)
>>> >>   ret i1 %z
>>> >> }
>>> >>
>>> >> According to
http://www.cplusplus.com/reference/cstdlib/malloc/,
>>> malloc may
>>> >> return null if this memory allocation fails. So why we
assume malloc()
>>> >> always returns a non-null pointer here?
>>> >>
>>> >> I think we can do such optimization with operator new,
because new
>>> never
>>> >> returns null. But for all malloc like allocation(malloc,
calloc, and
>>> new
>>> >> with std::nothrow), we shouldn't do this.
>>> >>
>>> >> That regression test exists for a long time, I'm not
sure if there's
>>> any
>>> >> special reason. Does anybody know about this?
>>> >>
>>> >> --
>>> >> Thanks,
>>> >>
>>> >> Kevin Qin
>>> >>
>>> >> _______________________________________________
>>> >> LLVM Developers mailing list
>>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>> >>
>>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> Kevin Qin
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150331/efb30d4e/attachment.html>

Kevin Qin

2015-Apr-01 07:15 UTC

head link

[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

Hi David and Mats,

Thanks for your explanation. If my understanding is correct, it means we
don't need to consider the side-effect of malloc/free unless compiling with
-ffreestanding. Because without -ffreestanding, user defined malloc/free
should be compatible with std library. It makes sense to me.

My point is, in std library, malloc is allowed to return null if this
malloc failed. Why compiler knows it must succeed at compile time?  I
slightly modified the regression case,

define i1 @CanWeMallocWithSize(i32 a) {
; CHECK-LABEL: @foo(
; CHECK-NEXT: ret i1 false
  %m = call i8* @malloc(i32 a)
  %z = icmp eq i8* %m, null
  call void @free(i8* %m)
  ret i1 %z
}

It's possible that this function is used to detect whether the runtime
environment can malloc a block of memory with size a. Besides, this
function can help to apply a large block of memory from system to memory
allocator and reduce the system call from a lot of malloc with small size
next. At some extreme situations, it may fail to pass this check, then
program can show a decent error message and stop. So the problem is, it's
not simply malloc a size of memory and then directly free it, but the
pointer from malloc is used to compare with null and finally affect the
return value. So this optimization may change the original semantic.


Thanks,
Kevin

2015-04-01 12:52 GMT+08:00 David Majnemer <david.majnemer at gmail.com>:
>
>
> On Tue, Mar 31, 2015 at 7:59 PM, Jiangning Liu <liujiangning1 at
gmail.com>
> wrote:
>
>> Hi Mats,
>>
>> I think Kevin's point is malloc can return 0, if malloc/free pair
is
>> optimized way, the semantic of the original would be changed.
>>
>> On the other hand, malloc/free are special functions, but programmers
can
>> still define their own versions by not linking std library, so we must
>> assume malloc/free always have side-effect like other common functions,
>> unless we know we will link std library only at link-time.
>>
>
> If programmers want to do this, they need to compile their program with
> -ffreestanding.
>
>
>>
>> Thanks,
>> -Jiangning
>>
>>
>> 2015-03-31 17:51 GMT+08:00 Kevin Qin <kevinqindev at gmail.com>:
>>
>>> Yes, I classified `new (std::nothrow)` to be a malloc like
allocation.
>>> See the next sentence.
>>>
>>>
>>> 2015-03-31 17:48 GMT+08:00 mats petersson <mats at
planetcatfish.com>:
>>>
>>>> > I think we can do such optimization with operator new,
because new
>>>> never returns null.
>>>>
>>>> This is incorrect in the case of `new (std::nothrow) ...` - the
whole
>>>> point of `(std::nothrow)` is to tell new that it should return
NULL in
>>>> case of failure, rather than throw an exception (bad_alloc).
>>>>
>>>> But the point here is not the actual return value, but the fact
that
>>>> the compiler misses that the constructor has side-effects.
>>>>
>>>> --
>>>> Mats
>>>>
>>>>
>>>>
>>>> On 31 March 2015 at 10:44, mats petersson <mats at
planetcatfish.com>
>>>> wrote:
>>>> > The optimisation here is that "nothing uses `m`, so
we can assume
>>>> > allocation works and remove the malloc + free pair".
>>>> >
>>>> > What is the purpose of allocating 1 (or 100, or
1000000000) bytes,
>>>> > never use it, and then free it immediately?
>>>> >
>>>> > The test-code in the bug report does rely on the
constructor being
>>>> > called, and the bug here is probably [as I'm not
familiar with the
>>>> > workings of the compiler in enough detail] that it
doesn't recognize
>>>> > that the constructor has side-effects.
>>>> >
>>>> > --
>>>> > Mats
>>>> >
>>>> > On 31 March 2015 at 10:24, Kevin Qin <kevinqindev at
gmail.com> wrote:
>>>> >> Hi,
>>>> >>
>>>> >>
>>>> >> When looking into the bug in
>>>> https://llvm.org/bugs/show_bug.cgi?id=21421, I
>>>> >> found a regression test in
>>>> Transforms/InstCombine/malloc-free-delete.ll
>>>> >> against me to directly fix it. The test is,
>>>> >>
>>>> >> define i1 @foo() {
>>>> >> ; CHECK-LABEL: @foo(
>>>> >> ; CHECK-NEXT: ret i1 false
>>>> >>   %m = call i8* @malloc(i32 1)
>>>> >>   %z = icmp eq i8* %m, null
>>>> >>   call void @free(i8* %m)
>>>> >>   ret i1 %z
>>>> >> }
>>>> >>
>>>> >> According to
http://www.cplusplus.com/reference/cstdlib/malloc/,
>>>> malloc may
>>>> >> return null if this memory allocation fails. So why we
assume
>>>> malloc()
>>>> >> always returns a non-null pointer here?
>>>> >>
>>>> >> I think we can do such optimization with operator new,
because new
>>>> never
>>>> >> returns null. But for all malloc like
allocation(malloc, calloc, and
>>>> new
>>>> >> with std::nothrow), we shouldn't do this.
>>>> >>
>>>> >> That regression test exists for a long time, I'm
not sure if there's
>>>> any
>>>> >> special reason. Does anybody know about this?
>>>> >>
>>>> >> --
>>>> >> Thanks,
>>>> >>
>>>> >> Kevin Qin
>>>> >>
>>>> >> _______________________________________________
>>>> >> LLVM Developers mailing list
>>>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> >>
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> Kevin Qin
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>

-- 
Best Regards,

Kevin Qin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150401/b9aa3bd7/attachment.html>

Reasonably Related Threads

Search for more seemingly similar threads

llvm dev - Apr 2015 - [LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

Reasonably Related Threads