5 ms·

Is Go not optimizing out the dead code in those examples because of those debug flags? Or does it not do that in general? Or is it just doing the bounds check

Is Go not optimizing out the dead code in those examples because of those debug flags? Or does it not do that in general? Or is it just doing the bounds check elimination (and debug messages about it) before the dead code elimination?

JamesMcMinn 10y ago
Go handles dead code by not allowing you to compile something with dead code. In the examples the "_ =" is needed to force it to compile and do the work without actually assigning the value to anything.
- junke 10y ago
  Suppose you "go generate" code which ends up having something along the lines of: x := true var y = 0 if x { y = 10 } else { y = 20 } In that case dead code elimination might require a little more analysis than checking for unassigned expressions and unused variables. So the question might be: what kind of dead code elimination exist in the compiler, apart from what you describe which has existed since the beginning of Go? (if I understand correctly)
- fizzbatter 10y ago
  Perhaps i misunderstand you, but isn't simply calling a function the same as what you quoted? Eg, `_ := Foo()` is the same as `Foo()`. No assignment needed. `_` mainly exists to allow ignoring single values, within multiple. Eg, dropping an error: `val, _ := MightError()`
  - JamesMcMinn 10y ago
    Foo() can have side-effects, taking a value from an array cannot, so Foo() is not necessarily dead code, whilst a[0] certainly is. _ serves multiple purposes, not just for ignoring a return value. It's often used when you care about the side effect but not the return value, such as importation a driver for a database . You'll never use the library, so you import it as _ "db.driver.name/path/".
    - euyyn 10y ago
      Can't taking a value from an array result in a panic? Quite the side effect.
- chrisseaton 10y ago
  > Go handles dead code by not allowing you to compile something with dead code. This is obviously not true and is easily disproved. Here's a program that compiles but has statically provably dead code on line 15 https://play.golang.org/p/_XcxezHV-6 https://play.golang.org/p/_XcxezHV-6. But even if I couldn't give you an example like that where the dead code is obvious, dead code is produced by the compiler itself as it optimises, and by code generation tools.
kevhito 10y ago
In C/C++, out-of-bounds memory access is in undefined behavior, so the compiler can assume it is a nop, so it is dead code and eliminate it. In go, out-of-bounds array/slice access is equivalent to calling panic. So _ = a[i] isn't dead code unless you can be sure that a[i] is in bounds. So yes, I imagine BCE should come before dead code elimination.
- e3b0c 10y ago
  I don't think bounds checking can be done at compile-time, especially in C/C++.
  - XMPPwocky 10y ago
    Not in the general case. char x[4]; printf("%c", x[4]); That's pretty easy to detect.
    - ithkuil 10y ago
      here you're talking about compile time bound check _elimination_, i.e. statically determine when you can remove a runtime bound check which would have been added by the compiler. I think e3b0c was talking about completely static bound checks.
      - codys 10y ago
        No. We can look at the example given above and clearly know/prove that the access is out of bounds. ie: a C compiler could emit a diagnostic (or decide it's undefined behavior and treat it as unreachable). There aren't any bounds checks above to eliminate.
  - deleted 10y ago
    [deleted]
- IshKebab 10y ago
  I think he means that the result isn't used.

JamesMcMinn 10y ago

Go handles dead code by not allowing you to compile something with dead code. In the examples the "_ =" is needed to force it to compile and do the work without actually assigning the value to anything.

junke 10y ago
Suppose you "go generate" code which ends up having something along the lines of: x := true var y = 0 if x { y = 10 } else { y = 20 } In that case dead code elimination might require a little more analysis than checking for unassigned expressions and unused variables. So the question might be: what kind of dead code elimination exist in the compiler, apart from what you describe which has existed since the beginning of Go? (if I understand correctly)
fizzbatter 10y ago
Perhaps i misunderstand you, but isn't simply calling a function the same as what you quoted? Eg, `_ := Foo()` is the same as `Foo()`. No assignment needed. `_` mainly exists to allow ignoring single values, within multiple. Eg, dropping an error: `val, _ := MightError()`
- JamesMcMinn 10y ago
  Foo() can have side-effects, taking a value from an array cannot, so Foo() is not necessarily dead code, whilst a[0] certainly is. _ serves multiple purposes, not just for ignoring a return value. It's often used when you care about the side effect but not the return value, such as importation a driver for a database . You'll never use the library, so you import it as _ "db.driver.name/path/".
  - euyyn 10y ago
    Can't taking a value from an array result in a panic? Quite the side effect.
chrisseaton 10y ago
> Go handles dead code by not allowing you to compile something with dead code. This is obviously not true and is easily disproved. Here's a program that compiles but has statically provably dead code on line 15 https://play.golang.org/p/_XcxezHV-6 https://play.golang.org/p/_XcxezHV-6. But even if I couldn't give you an example like that where the dead code is obvious, dead code is produced by the compiler itself as it optimises, and by code generation tools.

kevhito 10y ago

In C/C++, out-of-bounds memory access is in undefined behavior, so the compiler can assume it is a nop, so it is dead code and eliminate it. In go, out-of-bounds array/slice access is equivalent to calling panic. So _ = a[i] isn't dead code unless you can be sure that a[i] is in bounds. So yes, I imagine BCE should come before dead code elimination.

e3b0c 10y ago
I don't think bounds checking can be done at compile-time, especially in C/C++.
- XMPPwocky 10y ago
  Not in the general case. char x[4]; printf("%c", x[4]); That's pretty easy to detect.
  - ithkuil 10y ago
    here you're talking about compile time bound check _elimination_, i.e. statically determine when you can remove a runtime bound check which would have been added by the compiler. I think e3b0c was talking about completely static bound checks.
    - codys 10y ago
      No. We can look at the example given above and clearly know/prove that the access is out of bounds. ie: a C compiler could emit a diagnostic (or decide it's undefined behavior and treat it as unreachable). There aren't any bounds checks above to eliminate.
- deleted 10y ago
  [deleted]
IshKebab 10y ago
I think he means that the result isn't used.