[dmd-internals] non-PODs again

[Johannes Pfau]

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, 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.

-- 
Johannes Pfau