Distribute LLVM IR for libponyrt, use WPO by default for release-build pony programs.

[jemc]

I'm opening this ticket to capture some important discussion from another ticket, which got dropped when that ticket was closed: #1331 (comment)

The gist of the discussion, as I understand it, is that we should try to distribute LLVM bitcode for libponyrt as part of a ponyc installation.

When doing release builds of a pony program, we'd link against the LLVM bitcode for libponyrt instead of the shared library, and we'd enable whole-program-optimization (WPO). This would result in better-optimized pony program binaries. The binaries would also be independent of libponyrt, and could thus be distributed more easily to end-users of Pony-language programs, without those end-users needing to have their own Pony-language installation - similar to how Go static binaries are independent of any Go-language dependencies for the end user.

The disadvantages are:

• The static binaries that include libponyrt inside of them will be larger than those that link to it dynamically.
  • This is pretty much unavoidable, but probably not that big of a deal - this is only really a disk space disadvantage if the end user is going to be running a lot of different Pony-language programs, which is not really a problem that we have at this time. I think the advantages that we get with better portability and execution speed far outweigh this concern.
• Building ponyc will be more tightly coupled to clang, and it's not clear to me that we can still continue to support gcc as a compiler.
  • This is a big change, and something I was opposed to at first. However, as @Praetonus noted, we already require LLVM, and LLVM usually comes bundled with clang in the same installation (and even when they do come in separate packages, both should be equally easy to obtain for your system). I've come around to believing that this is not a significant burden on the user-developer, and will significantly reduce the burden on maintenance of the language itself - I seem to recall we've had a lot of tickets come from supporting old or new or differently-configured versions of GCC.
• Building release builds of pony programs will be slower, as it will be analyzing more LLVM bitcode, and making more optimizations.
  • This is also to be expected for building programs that are more heavily optimized. To mitigate this concern, we'd leave debug builds nice and fast, so that development iterations can still happen as quickly as possible. Making release builds of pony programs will be slower, but the resulting programs will be faster - which seems like the right tradeoff to be making for release builds.

[jemc]

I'm filing this ticket to make sure my understanding is correct, discover what work is required to push this forward, and start working toward this end, if we can agree that we're making the right tradeoffs as I described above. My end-goal is to have Pony support creating static binaries as easily and as portably as languages like Go do.

@SeanTAllen Maybe some Wallaroo Labs folks might want to collaborate on this as well, since it should make it easier for their end-users to install and use Wallaroo?

[jemc]

It looks like this is at least partially complete with #1058, but it's currently an optional process that takes extra work on the user-developer side to make it happen, rather than something that's available by default.

[SeanTAllen]

@jemc sounds interesting. definitely good for us long term but, not something we'd be able to do much on for at least a couple months.

[jemc]

It looks like the next logical step is make it so that the libponyrt bitcode gets built for ponyc releases, and bundled with the distribution of ponyc binaries, just like we bundle the pony code for the standard libraries.

Note that this means that our ponyc releases would need to be to built with clang so that they could build the bitcode.

We can do this fairly easily on linux and macos, but windows will take a little longer. We don't have to do it all at once.