We use ThinLTO for linking, but we use it in a way that doesn't give
most of its benefits: we merge all the bitcode files into a single LLVM
module and run some optimizations on it before linking. Therefore, this
works more like a traditional "full" LTO link rather than a true thin
link.
This commit adds a new experimental -lto=thin option to do a true
ThinLTO link. The main benefit is that linking will be a lot faster,
especially for large programs consisting of many packages.
At the moment, it only works for programs that don't do interface type
asserts and don't call interface methods. It also probably won't work on
WebAssembly and baremetal systems. But it's part of a larger goal
towards a truly incremental build system:
https://github.com/tinygo-org/tinygo/issues/2870
Once interface type asserts and method calls are converted to a
vtable-like implementation, most programs should just work on
linux/darwin/windows.
This is really a few more-or-less separate changes:
* Remove all math aliases that were used in Go 1.16 and below (the
math.[A-Z] aliases).
* Replace math aliases with an assembly implementation (the math.arch*
aliases) with a LLVM intrinsic, where one is available.
* Include missing math functions in picolibc build.
This leaves just four math aliases:
* math.archHypot and math.archModf do not have a LLVM builtin
equivalent. They could be replaced with calls to libm, and I think
that would be a good idea in the long term.
* math.archMax and math.archMin do have a LLVM builtin equivalent
(llvm.maximum.f64, llvm.minimum.f64), but unfortunately they crash
when used. Apparently these exact operations are not yet widely
supported in hardware and they don't have a libm equivalent either.
There are more LLVM builtins that we could use for the math package
(such as FMA), but I will leave that to a future change. It could
potentially speed up some math operations.
ed25519vectors_test.go still fails because:
* It relies on "go mod download" which doesn't work, as well as fork/exec.
* It relies on JSON parsing which has problems with reflection.
But, with the vectors hard coded in the test file the tests *do* succeed, so the encryption is working.
llvm.AddBasicBlock should never be used. Instead, we should use the
AddBasicBlock method of the current LLVM context.
This didn't lead to any bugs... yet. But probably would, eventually.
This commit adds support for the following packages:
- crypto/md5
- crypto/sha1
- crypto/sha256
- crypto/sha512
They would normally need assembly implementations, but with these
aliases they already work everywhere.
This makes them more flexible, especially with Go 1.17 making the
situation more complicated (see
https://github.com/golang/go/commit/1d20a362d0ca4898d77865e314ef6f73582daef0).
It also makes it possible to do the same for many other functions, such
as assembly implementations of cryptographich functions which are
similarly dependent on the architecture.
Ayke van Laethem
Avi
learnforpractice