To POD or not to POD (page 2)

Am Wed, 13 Feb 2013 17:17:06 +0000 schrieb Iain Buclaw <ibuclaw@ubuntu.com>: > On 13 February 2013 15:20, Iain Buclaw <ibuclaw@ubuntu.com> wrote: > > >> > >> Complete test case: > >> https://gist.github.com/jpf91/4944999 > >> > >> ----- > >> > >> ../../objdir-4.7/x86_64-unknown-linux-gnu/libphobos/dm-test.reduced/datetime2.d:22: > >> internal compiler error: in create_tmp_var, at gimplify.c:479 > >> 0x804509 ----- > >> > >> > > > > Ahh, that's because of this piece of codegen: > > > > SAVE_EXPR <*test.Date.this (&((void) (__ctmp971 = > > _D4test4Date6__initZ);, __ctmp971), 0)> > > > > > > Gimple doesn't like the dereference in SAVE_EXPR. This should work. > > > > tree > > IRState::makeTemp (tree t) > > { > > tree type = TREE_TYPE (t); > > if (TREE_CODE (type) != ARRAY_TYPE && !TREE_ADDRESSABLE (type)) > > return save_expr (t); > > > > return stabilize_reference (t); > > } > > > > > > So the generated code is now: > > > > *SAVE_EXPR <test.Date.this (&((void) (__ctmp971 = > > _D4test4Date6__initZ);, __ctmp971), 0)> > > > > > After some more playing about, David's suggestion would be the quickest. ;-) > Indeed. But what if the example is slightly adjusted to define a destructor or postblit instead of the constructor? Does the backend know about those or would it still try to pass Date in registers? For this current test case the issue seems to be that DMD creates a StructLiteralExp for the default constructor call which is of course not an lvalue and gimple seems to dislike that. But I don't know how to fix this and there could be many more cases...

February 13, 2013

Re: To POD or not to POD

Posted by Iain Buclaw
in reply to Johannes Pfau

Permalink

Iain Buclaw

Posted in reply to Johannes Pfau

Attachments:

text/html part

Permalink

On Feb 13, 2013 6:55 PM, "Johannes Pfau" <nospam@example.com> wrote:
>
> Am Wed, 13 Feb 2013 17:17:06 +0000
> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
>
> > On 13 February 2013 15:20, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >
> > >>
> > >> Complete test case:
> > >> https://gist.github.com/jpf91/4944999
> > >>
> > >> -----
> > >>
> > >>
../../objdir-4.7/x86_64-unknown-linux-gnu/libphobos/dm-test.reduced/datetime2.d:22:
> > >> internal compiler error: in create_tmp_var, at gimplify.c:479 0x804509 -----
> > >>
> > >>
> > >
> > > Ahh, that's because of this piece of codegen:
> > >
> > > SAVE_EXPR <*test.Date.this (&((void) (__ctmp971 =
> > > _D4test4Date6__initZ);, __ctmp971), 0)>
> > >
> > >
> > > Gimple doesn't like the dereference in SAVE_EXPR.  This should work.
> > >
> > > tree
> > > IRState::makeTemp (tree t)
> > > {
> > >   tree type = TREE_TYPE (t);
> > >   if (TREE_CODE (type) != ARRAY_TYPE && !TREE_ADDRESSABLE (type))
> > >     return save_expr (t);
> > >
> > >   return stabilize_reference (t);
> > > }
> > >
> > >
> > > So the generated code is now:
> > >
> > > *SAVE_EXPR <test.Date.this (&((void) (__ctmp971 =
> > > _D4test4Date6__initZ);, __ctmp971), 0)>
> > >
> > >
> > After some more playing about, David's suggestion would be the quickest. ;-)
> >
>
> Indeed. But what if the example is slightly adjusted to define a destructor or postblit instead of the constructor? Does the backend know about those or would it still try to pass Date in registers?
>

Backend doesn't know of those, and yes it would pass it in registers because it will always see structs as a value type rather than a reference (though passing round 'this' should always be done in memory).

Regards
Iain.

On Feb 13, 2013 6:55 PM, "Johannes Pfau" <nospam@example.com> wrote: > > Am Wed, 13 Feb 2013 17:17:06 +0000 > schrieb Iain Buclaw <ibuclaw@ubuntu.com>: > > > On 13 February 2013 15:20, Iain Buclaw <ibuclaw@ubuntu.com> wrote: > > > > >> > > >> Complete test case: > > >> https://gist.github.com/jpf91/4944999 > > >> > > >> ----- > > >> > > >> ../../objdir-4.7/x86_64-unknown-linux-gnu/libphobos/dm-test.reduced/datetime2.d:22: > > >> internal compiler error: in create_tmp_var, at gimplify.c:479 0x804509 ----- > > >> > > >> > > > > > > Ahh, that's because of this piece of codegen: > > > > > > SAVE_EXPR <*test.Date.this (&((void) (__ctmp971 = > > > _D4test4Date6__initZ);, __ctmp971), 0)> > > > > > > > > > Gimple doesn't like the dereference in SAVE_EXPR. This should work. > > > > > > tree > > > IRState::makeTemp (tree t) > > > { > > > tree type = TREE_TYPE (t); > > > if (TREE_CODE (type) != ARRAY_TYPE && !TREE_ADDRESSABLE (type)) > > > return save_expr (t); > > > > > > return stabilize_reference (t); > > > } > > > > > > > > > So the generated code is now: > > > > > > *SAVE_EXPR <test.Date.this (&((void) (__ctmp971 = > > > _D4test4Date6__initZ);, __ctmp971), 0)> > > > > > > > > After some more playing about, David's suggestion would be the quickest. ;-) > > > > Indeed. But what if the example is slightly adjusted to define a destructor or postblit instead of the constructor? Does the backend know about those or would it still try to pass Date in registers? > Backend doesn't know of those, and yes it would pass it in registers because it will always see structs as a value type rather than a reference (though passing round 'this' should always be done in memory). Regards Iain.

Forums