[dmd-internals] What does POD imply for backends
Iain Buclaw
ibuclaw at ubuntu.com
Sun Feb 17 13:59:35 PST 2013
On Feb 17, 2013 9:50 PM, "Iain Buclaw" <ibuclaw at ubuntu.com> wrote:
>
>
> On Feb 16, 2013 8:27 PM, "Walter Bright" <walter at digitalmars.com> wrote:
> >
> >
> > On 2/16/2013 12:17 PM, Johannes Pfau wrote:
> >>
> >> Am 16.02.2013 21:06, schrieb Walter Bright:
> >>>
> >>> A non-POD cannot be in registers because its address gets taken for
constructors/destructors.
> >>>
> >>>
> >> But creating temporary (bit) copies on the stack is still allowed for
non-PODs, right?
> >
> >
> > No.
> >
> >
> >>
> >> 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.
>
> Just catching up to speed with this, would this be passed by value on the
stack or by reference? (The latter would be easier, however the former
could probably be forced by adding some language hook to the backend in gdc
as a temporary workaround).
>
> Thanks,
> Iain.
By the way Johannes, the issue is clear I think. You can't make
temporaries with non-POD structs? This is something gdc is a bit zealous
in doing this around a lot of the code generation. So addressing that
would certainly fix problems around the other thread where you were marking
the type as addressable to prevent it being passed in registers.
Regards
Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20130217/70b9f280/attachment.html>
More information about the dmd-internals
mailing list