[llvm-dev] Skipping construction/destruction of stack allocated objects

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 15 20:17:05 PST 2019


This seems like a better discussion to have on cfe-dev than on llvm-dev
FWIW.

(I also happen to agree with Eli, but that's somewhat irrelevant.)

On Tue, Jan 15, 2019 at 7:16 PM Eli Friedman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 1/15/2019 6:09 PM, Alexandre Isoard via llvm-dev wrote:
> > Hello,
> >
> > For performance reasons, I would like to provide a way to skip
> > construction/destruction of objects that are stack allocated.
> > Typically, C-style arrays of std::complex create an initialization
> > loops that is almost always unnecessary.
> >
> > I am thinking of providing an __attribute__((uninitialized)) that can
> > be applied to an object declaration:
> >
> > {
> >     std::complex<float> foo[64][64] __attribute__((uninitialized));
> >     // does not need to generate a zeroinitializer loop here
> >     somefunction(foo);
> >     // does not need to generate a destructor loop here
> > (std::complex<float> don't have one anyway)
> > }
> >
> > Formally speaking, we won't call constructors/destructors on those
> > objects anymore. We would provide "uninitialized" memory in the same
> > meaning as malloc/free.
> >
> > Do you see this as a good idea? Do we already have a better way of
> > achieving this?
>
> The standard way to allocate uninitialized storage in C++ is
> std::aligned_storage.  The proposed extension doesn't really seem like
> an improvement over that.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/e6feddf2/attachment.html>


More information about the llvm-dev mailing list