I understood perfectly now, thanks for the explanations and the link! I really appreciate you guys!
On Thursday, September 24, 2020 at 3:28:10 AM UTC+3 Ian Lance Taylor wrote: > On Wed, Sep 23, 2020 at 1:10 AM cs.ali...@gmail.com > <cs.ali...@gmail.com> wrote: > > > > I am not actually questioning the current design, as you both said it is > not a good practice to call a return statement as I wrote above, I am > trying to understand the relation between memory, interface and order of > evaluation. It is clear that the compiler takes account of whether a return > statement is an interface or a struct and the memory size of the returned > value, If I return a struct rather than an interface, it changes the order, > If I add fields to the structs it changes the order. Is there a paper that > I can find why the compiler considers them for ordering, why it is > important for performance or anything else? > > I'm not aware of any paper specific to the Go compiler. > > I find it most useful to consider a compiler as creating a set of > constraints derived from the input based on the language semantics. > These are constraints like in "a = b; b = c" the read of b in the > first assignment must be completed before the store to b in the second > assignment. Once the set of constraints is created, the compiler must > solve those constraints given an instruction architecture including a > set of registers. The goal is to optimize execution time while > minimizing compilation time without violating any constraints. > Because compilation time matters, compilers do not fully analyze all > possible solutions; instead, when it comes to things like memory > load/store order, instruction selection, and register allocation, they > are full of heuristics that tend to give good results in practice. > > When you view a compiler in that way, a question like "why does adding > fields to a struct change the order of memory loads and stores" > becomes uninteresting. The reason has to do with the details of all > the constraints that applied while compiling that particular package. > There is no rule that says "if the struct has more fields, do this." > It's just that the set of heuristics happened to produce a particular > result. Changing some other piece of code in some other part of the > package might produce a different result. Or a different version of > the compiler might apply different heuristics and get different > results. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b2aa2ac3-a7da-4415-9534-7076551da5e7n%40googlegroups.com.
