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.
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
