Hacker News Reader

Comment by jjnoakes | Hacker News Reader

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?

View on HN

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.

I don't think bounds checking can be done at compile-time, especially in C/C++.

Not in the general case.

    char x[4];
    printf("%c", x[4]);

That's pretty easy to detect.

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.

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.

I think he means that the result isn't used.

Yes, but that doesn't matter: array indexing is not a "pure" function because it can panic. That's why you can't optimise it away, even if the result isn't used.

Ah I see.

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.

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)

> 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.

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.

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()`

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/".

Can't taking a value from an array result in a panic? Quite the side effect.

Reply on news.ycombinator.com