https://issues.dlang.org/show_bug.cgi?id=14912

kinke@gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke@gmx.net ---
Great find. I didn't like it either, but didn't realize the actual implementation isn't available for the optimizer!

--

https://issues.dlang.org/show_bug.cgi?id=14912

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I don't think this would be particularly difficult to change in dmd either as this kind of callee initializing already done for scoped classes and classes that have their own new(size_t) allocator.

--

https://issues.dlang.org/show_bug.cgi?id=14912

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Wouldn't it be enough to simply change the call to the opaque function
_d_newitemT(TypeInfo ti) to a template _d_newitem!(T)() ?

I don't want to put more special code in the compiler if possible.

--

https://issues.dlang.org/show_bug.cgi?id=14912

rsw0x <rsw0x@rsw0x.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsw0x@rsw0x.me

--- Comment #4 from rsw0x <rsw0x@rsw0x.me> ---
@Steven Schveighoffer

Unrelated, but this would help a lot in making a precise GC which is a reason to prefer going that route.

--

https://issues.dlang.org/show_bug.cgi?id=14912

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Steven Schveighoffer from comment #3)
> Wouldn't it be enough to simply change the call to the opaque function
> _d_newitemT(TypeInfo ti) to a template _d_newitem!(T)() ?
> 
> I don't want to put more special code in the compiler if possible.

Not really, because any potential optimization would stop at the memcpy, and not go any further.

I don't see what the complaint is?  The compiler has a much better idea of what is going on when it comes to initializing structures efficiently vs. a memcpy which is non-inlineable, and almost always falls into the slow, unaligned code path.

--

https://issues.dlang.org/show_bug.cgi?id=14912

--- Comment #6 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Why would a template need memcpy?

T *_d_newitem(T)()
{
   // could eliminate typeid here
   T *result = cast(T *)GC.malloc(T.sizeof, typeid(T).flags);
   *result = T.init;
   return result;
}

--

https://issues.dlang.org/show_bug.cgi?id=14912

--- Comment #7 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Steven Schveighoffer from comment #6)
> Why would a template need memcpy?
> 
> T *_d_newitem(T)()
> {
>    // could eliminate typeid here
>    T *result = cast(T *)GC.malloc(T.sizeof, typeid(T).flags);
>    *result = T.init;
>    return result;
> }

That's fine for anything except classes...

--

https://issues.dlang.org/show_bug.cgi?id=14912

--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Iain Buclaw from comment #7)
> That's fine for anything except classes...

Sure, but with compiler visibility, and ability to inline (and ability to alter the implementation based on the type), we can do whatever makes the optimizer happy.

All we need from the compiler is the components that make up the ci.init.

--

https://issues.dlang.org/show_bug.cgi?id=14912

--- Comment #9 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Steven Schveighoffer from comment #8)
> (In reply to Iain Buclaw from comment #7)
> > That's fine for anything except classes...
> 
> Sure, but with compiler visibility, and ability to inline (and ability to alter the implementation based on the type), we can do whatever makes the optimizer happy.
> 
> All we need from the compiler is the components that make up the ci.init.

Still need the ability to *deref a class to assign in bulk to its underlying structure in the language.  Currently only the compiler/codegen is allowed to do that.

--

https://issues.dlang.org/show_bug.cgi?id=14912

--- Comment #10 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Iain Buclaw from comment #9)
> (In reply to Steven Schveighoffer from comment #8)
> > (In reply to Iain Buclaw from comment #7)
> > > That's fine for anything except classes...
> > 
> > Sure, but with compiler visibility, and ability to inline (and ability to alter the implementation based on the type), we can do whatever makes the optimizer happy.
> > 
> > All we need from the compiler is the components that make up the ci.init.
> 
> Still need the ability to *deref a class to assign in bulk to its underlying structure in the language.  Currently only the compiler/codegen is allowed to do that.

And I read "from the compiler is the components that make up the ci.init" as a proposal for adding yet another property.

--