llvm dev - Apr 2018 - Malloc null checks, why sometimes are moved, and sometimes not?

> On 4/14/2018 3:09 AM, 陳韋任 wrote:
>> 2018-04-14 7:51 GMT+08:00 Krzysztof Parzyszek via llvm-dev
>> <llvm-dev at lists.llvm.org>:
>>> On 4/13/2018 6:39 PM, Dávid Bolvanský via llvm-dev wrote:
>>>> Here is simple test code:
>>>> https://godbolt.org/g/mjAUpu
>>>>
>>>> LLVM generally assumes that malloc never fails.
>>>>
>>>> But I dont understand difference between these two example
functions - and
>>>> why null check was not removed in f1, since in f2 it was
removed.
>>> That's because the return value from malloc is discarded in f2.
In that case
>>> it simply doesn't matter if the malloc happened or not, and can
be assumed
>>> to have succeeded.
>> Wouldn't such assumption be too aggressive?
> Normally, yes, but the standard explicitly allows the compiler to not 
> call allocation/deallocation functions if the storage can be provided in 
> another way. If the storage that would have been allocated by malloc 
> cannot ever be accessed, we can pretend that it has been successfully 
> provided in some way.
>
> -Krzysztof
How often does that really occur in normal programs?  Why bother? I find
it quite surprising to fold away the call.  While the pointer doesn't
escape F2(), the code does test the existance of the memory with the "if
(!ptr)".  That would be enough to retain the call on all the compilers
I've ever worked on.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180418/6095d53d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180418/6095d53d/attachment.sig>

The point is not to fold the check, the point is to promote heap
allocations to stack allocations when possible. Consider rewriting this:
   int *pz = new int(0);
   // use *p, do not escape p.
   delete p;
into:
   int z = 0;
   // use z in place of *p, do not escape &z.

The null check folds away as a consequence, not by design.
On Wed, Apr 18, 2018 at 12:25 PM John Reagan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 4/14/2018 3:09 AM, 陳韋任 wrote:
> 2018-04-14 7:51 GMT+08:00 Krzysztof Parzyszek via llvm-dev
> <llvm-dev at lists.llvm.org>:
> On 4/13/2018 6:39 PM, Dávid Bolvanský via llvm-dev wrote:
> Here is simple test code:
> https://godbolt.org/g/mjAUpu
> LLVM generally assumes that malloc never fails.
> But I dont understand difference between these two example functions - and
> why null check was not removed in f1, since in f2 it was removed.
> That's because the return value from malloc is discarded in f2. In that
case
> it simply doesn't matter if the malloc happened or not, and can be
assumed
> to have succeeded.
> Wouldn't such assumption be too aggressive?
> Normally, yes, but the standard explicitly allows the compiler to not
> call allocation/deallocation functions if the storage can be provided in
> another way. If the storage that would have been allocated by malloc
> cannot ever be accessed, we can pretend that it has been successfully
> provided in some way.
> -Krzysztof
> How often does that really occur in normal programs?  Why bother? I find
it quite surprising to fold away the call.  While the pointer doesn't
escape F2(), the code does test the existance of the memory with the "if
(!ptr)".  That would be enough to retain the call on all the compilers
I've
ever worked on.
> John
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev