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

Kevin Qin kevinqindev at gmail.com
Tue Mar 31 02:51:27 PDT 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150331/f8e721b5/attachment.html>


More information about the llvm-dev mailing list