http://bugzilla.gdcproject.org/show_bug.cgi?id=52

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau@gmail.com

-- 
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #1 from Iain Buclaw <ibuclaw@gdcproject.org> 2013-06-01 00:48:01 UTC ---
https://github.com/D-Programming-GDC/GDC/commit/38d4599d8cbae3ce8f29a1da46175503d2894f08


Before:
Construct: this=FFFFFFFFFFE36DD0
Check: this=FFFFFFFFFFE36DD0 a=FFFFFFFFFFE36DD0
Check: this=FFFFFFFFFFE36E40 a=FFFFFFFFFFE36DD0



After:
Construct: this=FFFFFFFFFF93C5E0
Check: this=FFFFFFFFFF93C5E0 a=FFFFFFFFFF93C5E0
Check: this=FFFFFFFFFF93C5F0 a=FFFFFFFFFF93C5E0


The offset between the two addresses are now 16 bytes apart.  However this is just evidence that GCC NRVO is not the same as DMD NRVO.  (I think DMD's way is passing the return variable as a hidden parameter).

But I'm content with this way of doing it for the time being.

-- 
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #2 from Johannes Pfau <johannespfau@gmail.com> 2013-06-01 11:47:43 UTC ---
I don't wanna nit pick but that doesn't fix the issue in typecons.d. The test case is a reduced test for scoped. It's not a check for some optimization, it's a check that makes sure that the class data is not moved when it's allocated with scoped!T. This is important as classes may have interior pointers.

I don't know if NRVO is actually part of the D spec. Depending on that we either have to make sure we don't move the value in gdc or we have to fix std.typecons.scoped in some other way.

-- 
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> 2013-06-01 13:27:31 UTC ---
(In reply to comment #2)
> I don't wanna nit pick but that doesn't fix the issue in typecons.d. The test case is a reduced test for scoped. It's not a check for some optimization, it's a check that makes sure that the class data is not moved when it's allocated with scoped!T. This is important as classes may have interior pointers.
> 

You mean not copied?


> I don't know if NRVO is actually part of the D spec. Depending on that we either have to make sure we don't move the value in gdc or we have to fix std.typecons.scoped in some other way.


It's mentioned only in the glossary... http://dlang.org/glossary.html

-- 
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #4 from Johannes Pfau <johannespfau@gmail.com> 2013-06-01 18:51:08 UTC ---
Well the address should not change to make sure interior pointers stay valid. Whether it's moved or copied doesn't matter in that case.

I think I remember Walter at some point said NRVO is guaranteed in D, although that doesn't say anything about how it should work yet. I can't find that post right now though.

-- 
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> 2013-06-12 23:03:51 UTC ---
Interestingly enough, the tests in the D2 testsuite for NRVO pass when compiled with -O1, but not with -O2 or -O3...

This attached test case is not affected at all regardless.

-- 
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #6 from Johannes Pfau <johannespfau@gmail.com> ---
One more simplified example:

http://dpaste.dzfl.pl/d5506e00d3be
----
import std.stdio;

struct S
{
  int a;
  int b;
  // Without this this small struct is returned in a register and even with DMD
  // the address is changing!
  int[64] c;
}

S nrvo()
{
  S s;
  s.a = 42;
  writeln(&s);
  return s;
}

void main()
{
  auto s = nrvo();
  writeln(&s);
}
----

Addresses are different with gdc, the same with dmd. However, as noted earlier there's nothing in the spec that tells us what's the correct behavior. The fact that even DMD does not prevent an address change if the struct is small enough to be returned in registers and that this whole 'feature' relies on ABI details probably shows that this is an anti-pattern.

We probably need an explicit way in the language to tell the compiler to allocate space in the caller and then pass a reference to the callee:

void nrvo(@caller ref S s)
{
    s.a = 42;
}

auto s = nrvo();
//the same as
S s;
nrvo(s);

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #7 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I blame Kenji for making it a language feature. :o)

By the way, +1 or -1 to emails sent in html format?

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #8 from Johannes Pfau <johannespfau@gmail.com> ---
These mails also got to the newsgroup? Then -1
otherwise I don't have a real opinion on that :-)

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=52

--- Comment #9 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to comment #8)
> These mails also got to the newsgroup? Then -1
> otherwise I don't have a real opinion on that :-)

Oh, these messages reach the newgroup just fine.  I'm just not used to seeing a strange format in bug emails.  That and I have to squint at some small text.

-- 
You are receiving this mail because:
You are watching all bug changes.