View mode: basic / threaded / horizontal-split · Log in · Help
February 13, 2013
Re: To POD or not to POD
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
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.
February 13, 2013
Re: To POD or not to POD
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home