mats petersson
2015-Mar-31 09:48 UTC
[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?
> 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 >>
Kevin Qin
2015-Mar-31 09:51 UTC
[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?
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>
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>