5 ms·

I filed a Go bug: https://github.com/golang/go/issues/20859 https://github.com/golang/go/issues/20859 We should just fix the compiler.

runeks 9y ago
I'm surprised Go doesn't compile down to an IR language where these differences in syntax are represented in a single manner. Seems like different ways to write the same thing.
- weberc2 9y ago
  I'm pretty sure Go does compile down to an IR, but it's little more than an abstraction over different architectures. I could be wrong.
  - hornetblack 9y ago
    Originally it compiled to Plan9 assembly which is cross platform. They have an SSA backend for some architectures now.
    - weberc2 9y ago
      I thought the SSA backend was not replacing the Plan9 assembly, but that it was a phase that happened before the assembly was output (presumably SSA is a phase and not an IR?).
      - hornetblack 9y ago
        Oh. That actually make more sense.
- bradfitz 9y ago
  It increasingly does. But it's been a process. Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax. Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like. Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 (https://golang.org/doc/go1.7#compiler https://golang.org/doc/go1.7#compiler). Go 1.8 included it for all architectures and added more SSA goodness. Go 1.9 adds yet more, but some things are still not pushed down into SSA as well as they could be. (e.g. https://github.com/golang/go/issues/5147#issuecomment-247685599 https://github.com/golang/go/issues/5147#issuecomment-247685...) Nowadays we can add optimizations much more easily, including writing matching rules like in https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/gen/generic.rules https://github.com/golang/go/blob/master/src/cmd/compile/int... Meanwhile the whole toolchain keeps getting cleaned up and more hackable. In Go 1.9, the compiler is now parallelized, which would've been impossible earlier. (https://tip.golang.org/doc/go1.9#parallel-compile https://tip.golang.org/doc/go1.9#parallel-compile) So, it keeps improving. Just remember the Hello World compiler we started with. Also amusing in retrospect is that when Go first came out, despite having a very basic compiler at the time, people coming from scripting languages thought we were so fast.
  - pcwalton 9y ago
    Just for what it's worth, the way I'd fix that problem in the compiler would be to implement dead store elimination via global value numbering. With trivial alias analysis, the compiler would be able to detect that the result of the "duffzero" instruction (which I assume is a memset) is always killed by the "duffcopy" instructions and would eliminate it. See this article for how it's done in LLVM: http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html http://blog.llvm.org/2009/12/introduction-to-load-eliminatio...
    - heythere124 9y ago
      Not my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads? var x Int // Pass x to a thread by reference x = 0 time.Sleep(1000) x = 1
      - Filligree 9y ago
        The answer to that one would be to embed thread-safety in the type system, aka. Rust. For languages with less sophisticated type systems you get a choice between inefficiency (Go), or complicated rules which state that the programmer is wrong for coding that way (C).
        heythere124 9y ago
        Your "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system. In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.
        Filligree 9y ago
        The constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.
- noselasd 9y ago
  It does if you use gcc though - both variants of the code in question here compiles to the same assembly (at least with gcc 7.1 on x86-84)
deleted 9y ago
[deleted]

runeks 9y ago

I'm surprised Go doesn't compile down to an IR language where these differences in syntax are represented in a single manner. Seems like different ways to write the same thing.

weberc2 9y ago
I'm pretty sure Go does compile down to an IR, but it's little more than an abstraction over different architectures. I could be wrong.
- hornetblack 9y ago
  Originally it compiled to Plan9 assembly which is cross platform. They have an SSA backend for some architectures now.
  - weberc2 9y ago
    I thought the SSA backend was not replacing the Plan9 assembly, but that it was a phase that happened before the assembly was output (presumably SSA is a phase and not an IR?).
    - hornetblack 9y ago
      Oh. That actually make more sense.
bradfitz 9y ago
It increasingly does. But it's been a process. Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax. Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like. Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 (https://golang.org/doc/go1.7#compiler https://golang.org/doc/go1.7#compiler). Go 1.8 included it for all architectures and added more SSA goodness. Go 1.9 adds yet more, but some things are still not pushed down into SSA as well as they could be. (e.g. https://github.com/golang/go/issues/5147#issuecomment-247685599 https://github.com/golang/go/issues/5147#issuecomment-247685...) Nowadays we can add optimizations much more easily, including writing matching rules like in https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/gen/generic.rules https://github.com/golang/go/blob/master/src/cmd/compile/int... Meanwhile the whole toolchain keeps getting cleaned up and more hackable. In Go 1.9, the compiler is now parallelized, which would've been impossible earlier. (https://tip.golang.org/doc/go1.9#parallel-compile https://tip.golang.org/doc/go1.9#parallel-compile) So, it keeps improving. Just remember the Hello World compiler we started with. Also amusing in retrospect is that when Go first came out, despite having a very basic compiler at the time, people coming from scripting languages thought we were so fast.
- pcwalton 9y ago
  Just for what it's worth, the way I'd fix that problem in the compiler would be to implement dead store elimination via global value numbering. With trivial alias analysis, the compiler would be able to detect that the result of the "duffzero" instruction (which I assume is a memset) is always killed by the "duffcopy" instructions and would eliminate it. See this article for how it's done in LLVM: http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html http://blog.llvm.org/2009/12/introduction-to-load-eliminatio...
  - heythere124 9y ago
    Not my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads? var x Int // Pass x to a thread by reference x = 0 time.Sleep(1000) x = 1
    - Filligree 9y ago
      The answer to that one would be to embed thread-safety in the type system, aka. Rust. For languages with less sophisticated type systems you get a choice between inefficiency (Go), or complicated rules which state that the programmer is wrong for coding that way (C).
      - heythere124 9y ago
        Your "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system. In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.
        Filligree 9y ago
        The constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.
noselasd 9y ago
It does if you use gcc though - both variants of the code in question here compiles to the same assembly (at least with gcc 7.1 on x86-84)

deleted 9y ago

[deleted]