llvm dev - Jan 2019 - Skipping construction/destruction of stack allocated objects

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?

I'm worried about the fact that for non-POD types it is not safe to ignore
that attribute, which probably means using an attribute is not a good fit...

-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/d0e22529/attachment.html>

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

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>