5 ms·

Compile times ? Flexibility over the backend ? That would be my hunch. I think it makes a lot of sense. Also, note that there is that project which exists : ht

• pcwalton 11y ago
  > Compile times ? There can be a compile time hit, but you can use FastISel, which is not bad. The compile time hit is mitigated by the fact that you get a far, far more mature series of optimization passes. Since the Go compiler is itself written in Go, more optimizations would make the Go compiler itself faster, further reducing the performance impact. > Flexibility over the backend ? Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like. This is what Swift, for example, is doing with SIL.
  • bassislife 11y ago
    > Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like. It still ignores toolchain flexibility. Especially given the specific needs of Go's managed runtime.
    • deleted 11y ago
      [deleted]
      • bassislife 11y ago
        > which LLVM now supports Key word being "now". I think you understood rather well. Also have a look at the supported architectures paragraph in the documents you linked.
        • sunnyps 11y ago
          And go 1.4+ doesn't just need segmented stacks but also moveable stacks. I do not know if LLVM has that yet.