[cfe-dev] Compiler optimizing out calls to new()

[via cfe-dev]

Thanks Hal and Richard,


Ø  The implementation is allowed to elide those side effects, and the standard was clarified in recent years to reflect this explicitly.

That settles it.

Thanks.

Sunil Srivastava

From: Finkel, Hal J. <hfinkel at anl.gov>
Sent: Monday, December 3, 2018 6:02 PM
To: Srivastava, Sunil <sunil.srivastava at sony.com>
Cc: Richard Smith <richard at metafoo.co.uk>
Subject: Re: [cfe-dev] Compiler optimizing out calls to new()

On 12/3/18 7:44 PM, via cfe-dev wrote:
Hi All,

A commit earlier this year, r325630, changed the behavior of the following program under -O1:

-----------------------------------------------------------------------------------
#include <new>
#include <stdlib.h>
extern "C" int printf(const char *, ...);
int UsedMyCode = 0;
void * operator new(std::size_t count)
{
    UsedMyCode = 1;
    return malloc(count);
}
int main(int argc, char * argv[])
{
    int* p = new int();
    *p = 10;
    printf("*p=%d.  UsedMyCode=%d\n", *p,  UsedMyCode);
    delete p;
    return 0;
}

The printed value of UsedMyCode became 0 after that checkin.

The compiler is eliminating the new/delete pair, printing just 10 for *p,  because  the usage
inside the function can be fully analyzed.

But I am wondering whether this is a valid optimization, because the implementation is not
calling the user supplied replacement as per 15.5.4.6. The complaint is that the side effects of
the user supplied replacement are not occurring.

The commit r325630 did not actually implement this optimization, but most likely it enabled
an already implemented optimization that was being foiled by something.

Any opinions?

The implementation is allowed to elide those side effects, and the standard was clarified in recent years to reflect this explicitly. See 8.3.4p10, "An implementation is allowed to omit a call to a replaceable global allocation function (21.6.2.1, 21.6.2.2). When it does so, the storage is instead provided by the implementation or provided by extending the allocation of another new-expression. The implementation may extend the allocation..."

 -Hal

Thanks

Sunil Srivastava
Sony Interactive Entertainment.




_______________________________________________

cfe-dev mailing list

cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>

http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

--

Hal Finkel

Lead, Compiler Technology and Programming Languages

Leadership Computing Facility

Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181205/d53a569b/attachment.html>