3 ms·

It doesnt look like this solves inlining library calls?

koenigdavidmj 10y ago
Go statically links to all Go libraries, and only dynamically links when interfacing with C code. (As of the last time I used it, a couple years ago; this may have changed since then.)
- spullara 10y ago
  That doesn't really answer whether it can inline library functions. The fact that it statically links means it potentially could inline methods it finds in them but I don't think that it does currently since it appears that this inline functionality works when compiling source.
  - ekiru 10y ago
    It can inline library functions, since, at latest, 1.4.2 (this is just what I happened to have handy on this computer). It's pretty easy to test by writing a package containing a simple function like "func Square(x int) int { return x * x }", compiling a main package that imports that package and calls Square, and then disassembling the executable to see whether it calls Square or inlines it.
- pjmlp 10y ago
  Go nowadays supports dynamic linking, just plugins aren't 100% supported across all targets.
aclements 10y ago
Go already performs cross-package inlining, so it can already inline library calls. (This is relatively easy to do in Go compared to other languages because packages must form a DAG. Compiling package A writes out enough information in the object file for A that compiling package B that depends on A can inline calls to functions in A.)
- DannyBee 10y ago
  "Compiling package A writes out enough information in the object file for A that compiling package B that depends on A can inline calls to functions in A" So it records the calling convention, architecture flags, alignment, and other ABI pieces etc? As well as an estimate of instruction-level inlining cost, summary info about arguments, etc, so you effectively decide whether inlining it will help or hurt, without having the IR around to try? FWIW: Writing out the info is usually not the hard part, actually, and is unrelated to the DAG-ness of the packages. GCC is just the perennial example here, but they refused to write it out for years for political reasons, not technical ones :)
  - aclements 10y ago
    "So it records the calling convention, architecture flags, alignment, and other ABI pieces etc?" No. At the moment it records the AST in the object file, because the inliner works at the Go AST level. In the future it may instead record the SSA representation (which would obviously give better cost estimates; the current heuristics are really extremely simple). "FWIW: Writing out the info is usually not the hard part, actually, and is unrelated to the DAG-ness of the packages." The DAG-ness means it's always available when compiling the call site, even if it's a cross-package call. It means you don't have to do it at link time.
    - DannyBee 10y ago
      "In the future it may instead record the SSA representation (which would obviously give better cost estimates; the current heuristics are really extremely simple)." This would be identical to what others do then :) "The DAG-ness means it's always available when compiling the call site, even if it's a cross-package call. It means you don't have to do it at link time. " This is unrelated to DAG-ness. Unless you mean something else by DAG-ness. DAG-ness means it's a directed-acyclic graph. That is, all other things being equal, it has no cycles. This is unrelated to the problem. For example, in other languages/etc, it could be weakly defined, or other some form of overridable, regardless of whether it has cycles, is actually multiply defined etc. That requires link-time resolution, becuase you can't optimize it making an assumption about its callees/callers, or even inline it, and then just hand that version to others because you may have screwed it up in a way one of those other callers depend on. That is, the overridability is an attribute of the function, not a problem of how it is used. Ditto on the ABI, alignment, etc. None of the interesting problems they have to solve are related to packaging. They occur with DAGs or non-DAGs, are just related to these languages supporting a richer set of things you can do to functions :)

Go statically links to all Go libraries, and only dynamically links when interfacing with C code. (As of the last time I used it, a couple years ago; this may have changed since then.)

spullara 10y ago
That doesn't really answer whether it can inline library functions. The fact that it statically links means it potentially could inline methods it finds in them but I don't think that it does currently since it appears that this inline functionality works when compiling source.
- ekiru 10y ago
  It can inline library functions, since, at latest, 1.4.2 (this is just what I happened to have handy on this computer). It's pretty easy to test by writing a package containing a simple function like "func Square(x int) int { return x * x }", compiling a main package that imports that package and calls Square, and then disassembling the executable to see whether it calls Square or inlines it.
pjmlp 10y ago
Go nowadays supports dynamic linking, just plugins aren't 100% supported across all targets.

aclements 10y ago

Go already performs cross-package inlining, so it can already inline library calls. (This is relatively easy to do in Go compared to other languages because packages must form a DAG. Compiling package A writes out enough information in the object file for A that compiling package B that depends on A can inline calls to functions in A.)

DannyBee 10y ago
"Compiling package A writes out enough information in the object file for A that compiling package B that depends on A can inline calls to functions in A" So it records the calling convention, architecture flags, alignment, and other ABI pieces etc? As well as an estimate of instruction-level inlining cost, summary info about arguments, etc, so you effectively decide whether inlining it will help or hurt, without having the IR around to try? FWIW: Writing out the info is usually not the hard part, actually, and is unrelated to the DAG-ness of the packages. GCC is just the perennial example here, but they refused to write it out for years for political reasons, not technical ones :)
- aclements 10y ago
  "So it records the calling convention, architecture flags, alignment, and other ABI pieces etc?" No. At the moment it records the AST in the object file, because the inliner works at the Go AST level. In the future it may instead record the SSA representation (which would obviously give better cost estimates; the current heuristics are really extremely simple). "FWIW: Writing out the info is usually not the hard part, actually, and is unrelated to the DAG-ness of the packages." The DAG-ness means it's always available when compiling the call site, even if it's a cross-package call. It means you don't have to do it at link time.
  - DannyBee 10y ago
    "In the future it may instead record the SSA representation (which would obviously give better cost estimates; the current heuristics are really extremely simple)." This would be identical to what others do then :) "The DAG-ness means it's always available when compiling the call site, even if it's a cross-package call. It means you don't have to do it at link time. " This is unrelated to DAG-ness. Unless you mean something else by DAG-ness. DAG-ness means it's a directed-acyclic graph. That is, all other things being equal, it has no cycles. This is unrelated to the problem. For example, in other languages/etc, it could be weakly defined, or other some form of overridable, regardless of whether it has cycles, is actually multiply defined etc. That requires link-time resolution, becuase you can't optimize it making an assumption about its callees/callers, or even inline it, and then just hand that version to others because you may have screwed it up in a way one of those other callers depend on. That is, the overridability is an attribute of the function, not a problem of how it is used. Ditto on the ABI, alignment, etc. None of the interesting problems they have to solve are related to packaging. They occur with DAGs or non-DAGs, are just related to these languages supporting a richer set of things you can do to functions :)