On Friday, 1 March 2013 at 13:59:08 UTC, Johannes Pfau wrote:
When trying to implement non-POD types for gdc some time ago I
asked on
the dmd mailing list what the backend is actually supposed to
do for
non-POD types. Walter answered that they should never be passed
in
registers:
--------------------------
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.
--------------------------
Now that's probably because of my weak C++ background, but what
can you
do with copy constructors that would break if the compiler
passed the
non-POD type in a register to a function?
Note: If I interpret this assembly properly dmd does do exactly
what
I proposed and what's illegal according to Walter:
D: https://gist.github.com/jpf91/5064703
ASM: https://gist.github.com/jpf91/5064764
Unsure what "pass in register" means. As in storing the data
before calling the function in a register, as opposed to the
stack?
In C++, if you ever copy or move anything, then a CC must be
called. Because of this, I'd say you can't place a non POD in a
register, because that would imply CC'ing the thing just to place
it in said register.
In D, it is a little different, because you are allowed to move
stuff in-memory without ever calling the CC. This is "D move
semantics", and it works because D bans internal pointers.
Because of this, I'd say you can pass by register.
Maybe Walter gave you his "reflex" C++ reply, and didn't realize
that D relaxed semantics changed the rules?
