[dmd-internals] non-PODs again

[Walter Bright]

On 3/7/2013 12:19 PM, Johannes Pfau wrote:
> Am 07.03.2013 20:45, schrieb Walter Bright:
>>
>> On 3/7/2013 9:36 AM, Johannes Pfau wrote:
>>> I'm sorry I have to pester you with this again, but I still have some 
>>> questions regarding POD types and I'd like to fix this in GDC.
>>>
>>> So from last discussion:
>>> >> Wouldn't it be legal to still pass non-PODs in registers when calling 
>>> functions and only copying them back to
>>> >> the stack if the address is needed? As we pass structs by value anyway, 
>>> how could this be problematic?
>>> >
>>> > No, not allowed. Consider why there are copy constructors, and what they do.
>>>
>>> I compiled some test programs with dmd and dmd _does_ pass non-POD values in 
>>> registers as I suggested above.
>>> See this example:
>>> https://gist.github.com/jpf91/5064703 (D)
>>> https://gist.github.com/jpf91/5064764 (ASM)
>>
>> That's because objects with constructors are now regarded as POD.
>
> This example uses a postblit to make sure the type is not a POD. It's obvious 
> in the ASM that the copy ctor is called,

Oops, I missed that. It's a bug in dmd.

> nevertheless the non-POD is passed in registers. Add a __traits(isPOD, Date) 
> test to the example, it returns false.
>>
>>>
>>> I also don't understand how a copy ctor could break this.
>>
>> Because a copy ctor executes arbitrary code, and this just does not work in 
>> the general case if a value is in a register.
>
> Yes, the struct value can't be passed _to the copy constructor_ in a register 
> - but the copy ctor itself is always called with a reference to the value, 
> i.e. it's declared as
> __copyctor(ref Date this, ref Date b)
>
> For all other functions I don't see why it can't be passed in a register.
>

The copy constructor must have its address. Registers don't have an address.