You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the assignment of the struct first allocates the struct on the stack and then memmoves it to the destination. The struct can be set on the destination immediately.
The text was updated successfully, but these errors were encountered:
Just took a look at this on the SSA branch.
You're right, there are two copies in the bad case, global data -> stack and stack -> destination.
The copies themselves are ok, if you do *dst = *src vs. dst.a, ... = src.a, ... the copy (using duffcopy) is slightly faster. It's the x2 that is the problem.
There doesn't seem to be an easy fix for this. For instance, if you do:
then the intermediate stack copy is necessary so you can modify the stack data before writing it. Direct assignments are still better in this case, but if the struct gets large enough the code size becomes prohibitive.
A rule like:
(Move dst inter (Move inter src mem)) -> (Move dst src mem)
might work. It's not quite that simple, as we have to make sure the intermediate memory isn't used by anyone else. And drop the inter variable if it is no longer used. And probably lots of other conditions I'm missing.
Long story short, thinking about it. Should be doable for the completely constant case.
Go1.5.1 windows/amd64
It seems that manually copying all the fields of a struct to a new location is faster than copying through assignment (which invokes
memmove
).Using
I think the assignment of the struct first allocates the struct on the stack and then
memmoves
it to the destination. The struct can be set on the destination immediately.The text was updated successfully, but these errors were encountered: